[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Profiling guile-gtk
From: |
Andy Wingo |
Subject: |
Profiling guile-gtk |
Date: |
Thu, 13 May 2004 22:50:44 +0100 |
Hey people,
(gnome gtk) is slow-loading, and it gets slower as GTK develops and
adds functions and types to their API. We got a problem, and we need to
figure out what to do.
I did some profiling on `guile -c '(use-modules (gnome gw gtk))'' with
qprof/libunwind. Here's how the time breaks down. About 9 seconds is the
total time on my machine. All numbers are, of course, statistical and
approximate.
Module Initialization time (% of total)
--------------------------------------------
gobject 3
atk 3
pango 2
gdk 4
gtk 72
============================================
TOTAL 84%
Other 16%
We'll deal with the remaining 16% later. Breaking down the 84% further,
still as percentages of the total time:
Part of wrapset registering Time (% of total) Procedure
-------------------------------------------------------------------
Making scheme functions 72 gw_wrapset_register
Making scheme classes 7 gtype->class
===================================================================
Total 79
Other 5
What's taking so long with the functions?
Part of function reg. Time (% of total) Procedure
----------------------------------------------------------------
Making generics 70 (!!!) gw_guile_procedure_to\
method_public
Making libffi stubs 2 [it's a smob type]
Now, of the 16% remaining:
Part of not-wrapset code Time (% of total)
-------------------------------------------------
Just loading guile ~2
Loading GOOPS ~1.5
Garbage collection ~6
ld.so ~5
=================================================
Total ~14.5
Other ~1.5
Note that I turned off GC while individual wrapsets were being
registered, as earlier profiles indicated GC was costing a lot. So
that's not so bad, only about 8% of code not accounted for -- if I did
the analysis correctly (I think I did, but not sure).
Where does this lead us? The obvious target is method definition. There
are two approaches to this: make the method registration go faster, and
delay the registration until later. Both are valid options, although the
latter will help us out more. There are again two ways to go about
delaying registration: by fully implementing the MOP for generics, and
overriding some default methods, or by using module-binder procedures. I
think the module-binder option is a better short-term solution. BTW: I
found that only 22% of that time was in scm_add_method. Line-by-line
profiling didn't work for me either. Damn, gotta start profiling in
scheme!
Normal procedures take suprisingly little time to register. I'm happy
about that.
The type code will become a problem as well: that 7% will go to 20-25%
when we take care of generics. Again, we need to tweak performance, as
well as delay registration. It's more straightforward to use binding
procedures with types, but we have to make sure that all of the types
for generics are defined when they are loaded.
Delayed binding will also ease the cost of GC. Perhaps instead of
turning it off during loading, we should just tune the parameters
differently. Dunno.
Then we have ld.so. I'm not sure on that number BTW, it's difficult
sometimes to see which functions are called where. I looked at Ulrich
Drepper's paper on DSOs, and it seems that 1) things are going to be
slower because we have lots of shlibs, and lots of symbols; and 2) we're
already doing the best we can: functions are prefixed to resolve
collisions quickly, and I started passing -Wl,-O1 on the link command
line. Dunno what else we can do, except maybe using dlopen() and dlsym()
instead. Or prelinking, whatever that is.
Well, that's the status. At least function loading is good. We just need
to fix types and generics now.
Cheers,
--
Andy Wingo <address@hidden>
- Profiling guile-gtk,
Andy Wingo <=