Re: Signal handlers: parameter names

["Padraig O'Briain" <Padraig Obriain Sun COM>]

I was making the general point that the most efficient engineering solution, 
with some startup cost and no runtime penalty, may not give the best perceived 
performance as user's views on performance are heavily influenced by startup 
costs.

I was not making a specific point about the issue at hand and am certainly not 
competent to comment on the test you did.

Padraig


> X-Sender: timj birgrave birnet private
> To: "Padraig O'Briain" <Padraig Obriain Sun COM>
> cc: jmargaglione yahoo com, cssl geocities com, Gtk+ Developers 
<gtk-devel-list gnome org>
> Subject: Re: Signal handlers: parameter names
> MIME-Version: 1.0
> 
> On Mon, 12 Mar 2001, Padraig O'Briain wrote:
> 
> > > John Margaglione wrote:
> > > > I'm not talking about invoking signals, I'm talking about creating a
> > > > dialog box to connect signals.  In Glade right now you can select a
> > > > signal by choosing from a list of available signals from a listbox.
> > > > When you choose one of the signals and generate the source code, Glade
> > > > has to do a lookup on the names of the parameters to the signal.  These
> > > > have to be stored as static arrays in the Glade source code.  If a new
> > > > signal is added, or the names of the parameters are changed, Glade has
> > > > to be updated.  Using my suggestion there is no rework of Glade
> > > > necessary.
> > > Then, why don't you use an XML file that describes them ? So :
> > > 0) no runtime penalty, except at startup (scan the XML file once and
> > > build tables in memory)
> > 
> > Startup costs are not insignificant. Perception of performance is probably 
more 
> > important than the results of any benchmark you run and perception of 
> > performance is very heavily influenced by startup time.
> > 
> 
> i see. that is, if we could get the startup time required for builders that
> will use text files to store signal arguments down to a reasonable
> minimum, this would be viable?
> attached is a sample parser for the syntax i suggested, timing it on a 550mhz
> machine with 1000 signal signatures ala:
> GtkCList::extend_selection (clist, scroll_type, position, 
auto_start_selection) return foobar;
> i'm getting:
> 
> parsed 1000 signal signatures
> 
> real    0m0.090s
> user    0m0.090s
> sys     0m0.000s
> 
> do you think that is an acceptable performance hit for your user base?
> 
> ---
> ciaoTJ