I sent some code to this list last week that might be useful for
this. 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).
On Apr 4, 2006, at 1:50 PM, Adam Wolff wrote:
> On Apr 4, Jim Grandy wrote:
> [snip]
>> Since hash lookup ought to be cheap on any reasonable JS runtime, I
>> could back off to consolidated routines that look up symbols in a
>> hash,
>> rather than completely split routines.
> I think this is the right thing to do.
>
> Some static hashes on view of this sort:
>
> LzView.prototype._lookups = { axes : { x : "width" , y :
> "height" },
> resource : { width : "resourcewidth" ,
> height:
> "resourceheight" },
> stretch : { width :
> "unstretchedwidth" ,
> height:
> "unstretchedheight" },
> ....
>
> would be generally useful.
>
> A
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
