On 2006-04-04, at 14:49 EDT, Oliver Steele wrote: > I sent some code to this list last week that might be useful for > this.
And apparently the mailing list manager just decided to release your message today! > It contained a version of _lookups with all the properties > referenced in these functions, and some of the changes necessary to > use this lookup table. > > Jim measured this and, to my surprise, it wasn't faster on Flash. I > guess the moral of this is that it's worth measuring whether the > change actually improves performance on some specific runtime, rather > than assuming that it might. > > However, there's an additional complexity that I just thought of. > The full cost of string construction might not show up in a profiler > because part of the cost is the increased object churn, which dials > up the gc frequency, and a profiling run wouldn't show this unless it > was long enough to trigger a statistically accurate number gcs. So a > table-driven approach, which substitutes the cost of hashing for the > cost of string construction, might still be faster over the long term > even if it measures out the same in a short run, by replacing string > allocation (pay not AND pay later) with hash lookup (pay only now). Unless we could know that the player had a good ephemeral gc, in which case the cost of allocating the string is a simple pointer increment and the cost of collecting it approaches 0 over the long term, whereas the cost of the hash lookup is a constant surely greater than the pointer increment. I think Jim ended up addressing this by splitting several functions that were parameterized. Of course, that introduces a maintenance issue. _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
