My suggestion was to emit code like this makeMap([12,35,123]) which is a
routine that produces {12:1, 35:1, 123:1}. I've run into cast checks as
being an overwhelming hot-method in the past, and I'd think that a loop,
even a small one, could add significant overhead. Something like makeMap()
would have slightly worse startup time, since it would have to turn all of
these arrays into maps during parse time, but then
during runtime, it's cheap.The middle ground could be makeMap() on first canCast() call, but even that would entail an extra check that might incur a cost. -Ray On Wed, Aug 11, 2010 at 10:20 AM, Scott Blum <[email protected]> wrote: > On Wed, Aug 11, 2010 at 12:56 PM, <[email protected]> wrote: > >> I think this makes sense, and would reduce the size of the generated >> code, e.g. "[12,35,123]" vs. "{12:1,35:1,123:1}". The Cast.canCast() >> methods would have to iterate through the array explicitly to test for >> existence though, instead of a simple object property lookup. Thoughts? >> RayC suggested something similar as well. > > > Hmm, dunno. The generate size won't change much after compression, I'd > guess. Hate to have to introduce an O(n) lookup there, but the only way to > know for sure if it's a win would be to test it in real apps. My suggestion > of int[] was actually based on the current data structure. Even though that > looks like Object literal syntax, for practical purposes it could > theoretically be treated as a sparse int[]. But that change wouldn't add > anything to your patch except perhaps readability. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
