Re: [Gnash-dev] Re: string_table::noCase

[strk]

On Thu, Aug 05, 2010 at 06:57:44PM +0200, strk wrote:

> What about caching the case-insensitive version of each key ?
> That could mean typedef'ing string_table::key to a pair of longs...

Took a better look, now I see we _are_ caching both keys..
To get back to the profile we then see ::noCase called
by both getProperty and setValue :

                0.02    0.00  852351/43713660     gnash::PropertyList::setValue(
gnash::ObjectURI const&, gnash::as_value const&, gnash::PropFlags const&) [51]
                0.06    0.00 2705748/43713660     gnash::getDisplayObjectPropert
y(gnash::DisplayObject&, unsigned long, gnash::as_value&) [13]
                0.17    0.00 7634220/43713660     gnash::DisplayList::getDisplay
ObjectByName(gnash::string_table&, unsigned long, bool) const [36]
                0.72    0.00 32493651/43713660     gnash::PropertyList::getPrope
rty(gnash::ObjectURI const&) const [17]
[22]    11.3    0.97    0.00 43713660         
gnash::string_table::noCase(unsigned long) const [22]

Given getProperty is called over 10 times more than setValue maybe one
optimization would be to avoid the ::noCase call for keys which are
known in advance for being lower-case (thinking about namedStrings).

Currently namedStrings seem to be ordered alphabetically.
Instead, if we put all lower-case ones at the start checking
we may avoid the noCase lookup when the key is below a given value...

I'll try how it goes.


--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html