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
_______________________________________________
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
