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 <[EMAIL PROTECTED]>
@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 Specification
