Mark Kvale: # Steve Fink recently made it easy to test parrot under various runtime # options: # # -g - suppress use of computed goto # -P - use prederef # -j - use JIT compiler # # I was curious to see what effects these would have on regex # timings for the various schemes I cooked up. As before, I am .... # Conclusions: # # 1) None of the runtime options make a huge difference in regex times, # but reg seems more susceptible to optimization than rx. # # 2) The two consistently fastest schemes are computed goto and the JIT # compiler. Suppressing computed goto or using prederef slows down # reg by 20-50%. rx is less affected, with a -4-10% slowdown # for -g or # -P. # # 3) In retrospect, the timing results quoted in my 'bakeoff' were near # optimal for the reg and rx schemes, as they all used the default # computed goto option. Another good e-mail. I can explain the rx results quite well. -No difference between prederef and JIT: the opcodes are too complicated for JIT to optimize well, so the two are essentially equivalent. -Little difference between different dispatches: Compared to reg, there are few ops, so reg will get a bigger boost from faster dispatches. BTW, I just committed three new opcodes: intsave, intrestore, and intdepth. These use the same sort of fast integer stack that rx uses, so reg might get a boost from them. --Brent Dax <brentdax@cpan.org> @roles=map {"Parrot $_"} qw(embedding regexen Configure) blink: Text blinks (alternates between visible and invisible). Conforming user agents are not required to support this value. --The W3C CSS-2 SpecificationThread Previous