Re: Some performance notes

[Tim Janik <timj gtk org>]

On 6 Aug 2001, Owen Taylor wrote:

> 
> Tim Janik <timj gtk org> writes:
> 
> > > Superficially glancing over the code in gobject.c I can see
> > > two possible reasons for the g_object_new() slowness:
> > > - properties are identified by strings, where g_param_spec_pool_lookup()
> > >   has to parse the class_name:property_name combination (twice, once in
> > >   g_object_new_valist, and again in g_object_newv)
> > 
> > the "class_name:property_name" syntax is strongly deprecated, people
> > should just use "property_name". g_param_spec_pool_lookup() first
> > attempts to lookup the property as "property_name" and only if that fails
> > falls back to looking for ':'. so don't use "class_name:" prefixing and
> > you don't pay extra string-contents-shuffling performance penalty for
> > deprecated API ;)
> 
> The strchr() in:
> 
>   delim = pool->type_prefixing ? strchr (param_name, ':') : NULL;
> 
> in g_param_spec_pool_lookup() was showing up at the few-percent level
> in my profiles. Maybe it's just an artifact of poor resolution
> that it shows up so high ...
> 
> (This string shuffling bit _is_ hit no matter if you use the feature
> or not.)

yep, one strchr() is hit for the normal case, however, with
string-contents-shuffling i meant g_strndup()ing the class portion
and similar string operations.
note that testgtk, despite class_name::property_name being deprecated,
still prefixes most property_names with class_name since that was
recommended pre-1.2. so it's triggering the g_param_spec_pool_lookup()
penalty fairly often.
also not that, for the common case we should be able to get rid of
the initial strchr() and depth(object_type)-1 string hashes, simply
by indexing the pool hashtable with pspec name quarks.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ