Meanwhile some thoughts on this topic: 1. I'm not sure about string comparisons, but I agree that for sparse smis binary search tree should be the fastest way to perform matching. 2. From my experience and previous benchmarks, hashmap lookup seems to be significantly slower than sequential check when there're not a lot of clauses (i.e. less than 64), also its hard to account strict equivalence testing when doing lookups in javascript maps, but you guys probably already have some tools for this stuff... 3. Mixed cases seems to be very rare and generally not really performance sensitive code, or at least I don't know any public example of their usage.
Cheers, Fedor. On Wed, Jun 5, 2013 at 12:57 PM, Fedor Indutny <fe...@indutny.com> wrote: > Ok, I'll wait for you guys to plan it. > > Cheers, > Fedor. > > > On Wed, Jun 5, 2013 at 11:35 AM, Sven Panne <svenpa...@chromium.org>wrote: > >> On Wed, Jun 5, 2013 at 8:47 AM, Sven Panne <svenpa...@chromium.org>wrote: >> >>> On Tue, Jun 4, 2013 at 6:02 PM, Fedor Indutny <fe...@indutny.com> wrote: >>> >>>> As a start for all this stuff that I'm probably going to (but after >>>> discussion this time!) I've opened this CL: >>>> https://codereview.chromium.org/15993014 . >>>> >>> >>> I'll take a look. >>> >>> >>>> Sven, I'd like to try implementing binary search tree, just to see if >>>> it changes the picture. Please let me know if it sounds like a good idea to >>>> you? >>>> >>> >>> I guess you're talking about the Smi-only case. Then a tree sounds OK, >>> although for dense cases (emulators!), a jump table will still be much >>> better. But first things first... >>> >> >> After looking at the CL, I'm even more convinced that we really need a >> design document before we actually land changes regarding switch. It is OK >> to experiment without a document, but don't expect to see things landed >> then. >> >> What I e.g. currently don't like is the knowledge about case clauses >> scattered around throughout our code base, where this can and actually >> should be calculated locally, useless deopts, etc. I have the gut feeling >> that we need some non-mechanical cleanup first + some kind of agreed-upon >> master plan... >> > > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
