Hi, <snip>
Ha, I use 6.4, which may be why I didn't see it taking more than 2 minutes. Please compile 6.4 and see if it fixes it for you. This will be an important result if it does.
Just tried CVS with your fix, it does improve the load time but not by much (was 1:50, now 1:39).
I just upgraded to boehm-gc 6.4 - and now the file loads in about 35s. Moreover, I can see the whole file unlike in the other programs I've tried. I'll also try to upgrade to the CVS version when it appears in a snapshot (I don't think it's there yet?)
Thanks, gav.
-- Gavin Band <gavinband@...663...>
___________________________________________________________
Book yourself something to look forward to in 2005. Cheap flights - http://www.tiscali.co.uk/travel/flights/ Bargain holidays - http://www.tiscali.co.uk/travel/holidays/
Bulia wrote:
Just tried CVS with your fix, it does improve the load time but not by much (was 1:50, now 1:39).
Yeah, in retrospect I'm not surprised. sp_object_attach_reref seems to have been dominating anyway (which also means that the virtual method call overhead really is negligible -- sp_object_attach_reref still uses direct member access).
Granted, I'm not certain how much speeding up sp_object_attach_reref will buy us, but it really is stupidly inefficient now and needs to be fixed.
In general the SPObject stuff is pretty bad, which is partly my fault and partly Lauris'. I'm not sure what either of us were thinking.
For example: SPObject *sp_object_get_child_by_repr(SPObject *object, SPRepr *repr) { g_return_val_if_fail(object != NULL, NULL); g_return_val_if_fail(SP_IS_OBJECT(object), NULL); g_return_val_if_fail(repr != NULL, NULL);
for ( SPObject *child = object->children ; child ; child = child->next ) { if ( SP_OBJECT_REPR(child) == repr ) { return child; } }
return NULL; }
(which is O(n))
Could trivially be rewritten as:
SPObject *sp_object_get_child_by_repr(SPObject *object, SPRepr *repr) { g_return_val_if_fail(object != NULL, NULL); g_return_val_if_fail(SP_IS_OBJECT(object), NULL); g_return_val_if_fail(repr != NULL, NULL);
SPObject *child = SP_OBJECT_DOCUMENT(object)->getObjectByRepr(repr); if ( child && SP_OBJECT_PARENT(child) == this ) { return child; } else { return NULL; } }
(which is O(1), at least, assuming a perfect hash function, but even without that never worse than O(n) and usually extremely better)
I will need to re-verify that this is never used to find clones, for which the second version wouldn't work, but I don't think it is.
On Fri, 2005-01-28 at 07:08, gavinband@...663... wrote:
I just upgraded to boehm-gc 6.4 - and now the file loads in about 35s.
Cool, I've been looking for confirmation that 6.4 fixes this particular GC bug! ^_^
Moreover, I can see the whole file unlike in the other programs I've tried.
Hmm, I wonder why that is. Our internals are not _that_ different from Sodipodi yet, except the renderer. But I'm glad to hear it. ^_^
-mental
On Fri, 28 Jan 2005 09:35:48 -0500, MenTaLguY <mental@...3...> wrote:
On Fri, 2005-01-28 at 07:08, gavinband@...663... wrote:
I just upgraded to boehm-gc 6.4 - and now the file loads in about 35s.
Cool, I've been looking for confirmation that 6.4 fixes this particular GC bug! ^_^
Mental, can you please make 6.4 required, so that it won't compile with 6.3?
Quoting bulia byak <buliabyak@...400...>:
Mental, can you please make 6.4 required, so that it won't compile with 6.3?
I'm not sure how. As far as I know there's no (portable) way to discriminate between 6.3 and 6.4 for the purposes of a ./configure test.
Even if it were possible, it'd still be a little awkward for me personally, since the Debian libgc maintainer hasn't yet packaged 6.4...
-mental
On Fri, 28 Jan 2005 13:55:45 -0500, mental@...3... <mental@...3...> wrote:
Mental, can you please make 6.4 required, so that it won't compile with 6.3?
I'm not sure how. As far as I know there's no (portable) way to discriminate between 6.3 and 6.4 for the purposes of a ./configure test.
There must be a way. Can you ask on the GC list?
On Fri, Jan 28, 2005 at 06:43:21PM -0400, bulia byak wrote:
On Fri, 28 Jan 2005 13:55:45 -0500, mental@...3... <mental@...3...> wrote:
Mental, can you please make 6.4 required, so that it won't compile with 6.3?
I'm not sure how. As far as I know there's no (portable) way to discriminate between 6.3 and 6.4 for the purposes of a ./configure test.
There must be a way. Can you ask on the GC list?
I added a libgc version test to configure.ac. There aren't very well documented methods to access the version info, but my test seems to do the trick:
+ AC_MSG_CHECKING([libgc version 6.4+]) + AC_RUN_IFELSE( + [AC_LANG_SOURCE([[ + #ifdef HAVE_GC_GC_H + # include <gc/gc.h> + #else + # include <gc.h> + #endif + extern unsigned GC_version; + int main(void){ + unsigned min = ((6 << 16) | (4 << 8) | 0); + if (GC_version>=min) return 0; + return 1; + }]])], + [gc_ok=yes], + [gc_ok=no] + ) + AC_MSG_RESULT([$gc_ok])
On Fri, 2005-01-28 at 17:43, bulia byak wrote:
On Fri, 28 Jan 2005 13:55:45 -0500, mental@...3... <mental@...3...> wrote:
Mental, can you please make 6.4 required, so that it won't compile with 6.3?
I'm not sure how. As far as I know there's no (portable) way to discriminate between 6.3 and 6.4 for the purposes of a ./configure test.
There must be a way. Can you ask on the GC list?
I did, but unless there was an API change I don't know about, the answer is going to be no. libgc doesn't use pkg-config or any of those nice tools.
-mental
participants (4)
-
unknown＠example.com -
bulia byak -
Kees Cook -
MenTaLguY