guile-gtk-general
[Top][All Lists]
Advanced

[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>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]