Re: optimizing NOP emissions (Re: [Nautilus-list] nautilus & signals)

[Michael Meeks <michael ximian com>]

Hi Tim, 

On Thu, 2002-04-11 at 23:45, Tim Janik wrote: 
> first, locks/unlocks don't need to be slow per-se, a pthread lock/unlock
> pair takes 40 nano seconds on my machine (550Mhz dual processor system).
Interesting - the thing is I'm looking at many tens of thousands of
g_signal_emits, and we do multiple lock/unlocks per signal emissions,
such that the top 3 things on the profile are (were) pthread_lock,
g_signal_emitv, pthread_unlock (AFAIR). 

> though what gthread adds on top of that is another matter, _locking_
> is definitely not a problem for gsignal.c (for gtype.c it was, and we
> fixed that).

	So I'm not so convinced about that ;-) 

> you got a point in NOP emissions though. the problem here is that it's
> 1) fairly hard to correctly figure that an emission is not neccessary
> 2) expensive too some extend, i.e. extra overhead is added to all
>    emissions which cannot be skipped.

	Yes - that's hard. 

> so for (2), what we need is somewhat representative profiling data, if it
> showes that either:
> - during normal program operations, there're much more signal emissions which
>   could be skipped than emissions which can not, or
> - the overhead to figure whether an emission could be skipped is negligable
>   compared to emitting a signal,
> optimizing NOP emissions is actually worth incorporating into the standard
> gobject distro.

	Ok; so here is my data - re-harvested just now ... 

export GOBJECT_DEBUG=signals 
nautilus 2>/tmp/nau.log 
cat /tmp/nau.log | sed 's/[^ ]* //' | sed 's/(.*//' | sort | uniq -c |
sort -n > /tmp/nau2.log 

    228 GtkWindow::notify 
    244 FMIconContainer::get-stored-icon-position 
    244 FMIconContainer::icon-added 
    244 FMIconView::add-file 
    276 GtkImageMenuItem::add 
    277 GtkImageMenuItem::show 
    278 GtkImageMenuItem::accel-closures-changed 
    304 GtkAccelGroup::accel-changed 
    313 GtkImageMenuItem::hierarchy-changed 
    313 GtkImageMenuItem::parent-set 
    340 GtkLabel::child-notify 
    345 GtkAccelLabel::show 
    348 GtkImageMenuItem::grab-notify 
    402 GtkAccelLabel::grab-notify 
    425 GtkMenuItem::notify 
    436 NautilusIconCanvasItem::destroy 
    467 GtkAccelLabel::parent-set 
    469 GtkAccelLabel::hierarchy-changed 
    498 NautilusVFSFile::destroy 
    732 GtkImage::notify 
    742 GtkLabel::notify 
    918 GtkImageMenuItem::notify 
   1787 NautilusIconCanvasItem::notify 
   2544 GtkAccelLabel::notify 

	This is of browsing a few folders in nautilus; so we have a fair number
of notifies going on - I assume all of which are NOOPs, but now I look
at it it looks like the signal problem is substantially slain, and the
GtkLabel patch I sent will fix a chunk of the above, so perhaps this is
a non-issue.

	Indeed, re-profiling shows that the signal / locking code is no longer
near the top of the profile for directory traversal; instead:

170 samples
Max Percent: 7%
draw_with_pixmaps                                          : 7.6% ( 13 )
__pthread_mutex_unlock                                     : 6.5% ( 11 )
free_check                                                 : 5.3% ( 9 )
Bonobo_ActivationProperty_copy                             : 2.9% ( 5 )
g_object_ref                                               : 2.4% ( 4 )
byte_re_search_2                                           : 2.4% ( 4 )
malloc_check                                               : 2.4% ( 4 )
g_hash_table_lookup                                        : 1.8% ( 3 )
gtk_default_render_icon                                    : 1.8% ( 3 )
g_param_spec_pool_lookup                                   : 1.8% ( 3 )
g_object_last_unref                                        : 1.2% ( 2 )
gnome_vfs_mime_try_one_magic_pattern                       : 1.2% ( 2 )
g_signal_emit_valist                                       : 1.2% ( 2 )
signal_emit_unlocked_R                                     : 1.2% ( 2 )
__libc_realloc                                             : 1.2% ( 2 )
__libc_free                                                : 1.2% ( 2 )
__pthread_mutex_lock                                       : 1.2% ( 2 )

	So I think it's not such a problem now.

	Regards,

		Michael.


-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot