in reply to Re: Re: transliterate
in thread transliterate

Which version of perl are you using?

5.005_03 seems to have a really slow tr///, that actually is slower than s/// (singe celeron 466)
Benchmark: timing 250000 iterations of one, two... one: 1 wallclock secs ( 0.83 usr + 0.00 sys = 0.83 CPU) two: 1 wallclock secs ( 0.74 usr + 0.00 sys = 0.74 CPU) Benchmark: timing 2000000 iterations of one, two... one: 7 wallclock secs ( 6.71 usr + 0.00 sys = 6.71 CPU) two: 6 wallclock secs ( 5.93 usr + 0.00 sys = 5.93 CPU)

However, 5.6.1 (on a dual p3 800) tr seems to be almost twice as fast.
Benchmark: timing 250000 iterations of one, two... one: 1 wallclock secs ( 0.26 usr + 0.00 sys = 0.26 CPU) @ 96 +1538.46/s (n=250000) (warning: too few iterations for a reliable count) two: 1 wallclock secs ( 0.46 usr + 0.00 sys = 0.46 CPU) @ 54 +3478.26/s (n=250000) Benchmark: timing 2000000 iterations of one, two... one: 2 wallclock secs ( 2.06 usr + 0.00 sys = 2.06 CPU) @ 97 +0873.79/s (n=2000000) two: 4 wallclock secs ( 3.68 usr + 0.00 sys = 3.68 CPU) @ 54 +3478.26/s (n=2000000)

I don't know too much about the tr/// and s/// code, but it looks like someone went and optimized tr/// between 5.005 and 5.6.1. (Would someone who knows (japhy?) please comment on this?)

Replies are listed 'Best First'.
Re: Re: Re: Re: transliterate
by trantor (Chaplain) on Jul 27, 2001 at 22:39 UTC

    It would be interesting to compare the results using Unicode strings. In this case, the difference between a character by character scan and a Finite State Machine could be greater, although the FSM generated by <ODE>s/ /+/g</CODE> is so simple that it is probably a character by character scan.

    -- TMTOWTDI