Started working over the Siesta web frontend. I hate developing web stuff, but it's one of the last few things that just have to be
built.
---
Remembered to release Mariachi 0.4, now with added slowness.
---
Started to think again on Devel::LeakTrace. Realised I was rampantly over-calling malloc for the most common cases and so shaved those a bit.
Timings went from:
% time perl -Mblib -MDevel::LeakTrace -e 'for (1..1000) {++$x}'
leaked SV(0x8140de0) from -e line 1
leaked SV(0x8140e1c) from -e line 1
perl -Mblib -MDevel::LeakTrace -e 'for (1..1000) {++$x}' 3.34s user 0.02s system 100% cpu 3.355 total
To:
% time perl -Mblib -MDevel::LeakTrace -e 'for (1..1000) {++$x}'
leaked SV(0x8140de0) from -e line 1
leaked SV(0x8140e1c) from -e line 1
perl -Mblib -MDevel::LeakTrace -e 'for (1..1000) {++$x}' 2.65s user 0.01s system 101% cpu 2.613 total
So a nice fat 25% speedup in a few easy steps.
Of course it's still burning way too many cycles in maintaining all the state. Compare the instant timings of an unladen perl.
% time perl -e 'for (1..1000) {++$x}'
perl -e 'for (1..1000) {++$x}' 0.00s user 0.00s system 0% cpu 0.000 total
Should tuits present themselves I'm going to see if Judy arrays really work well as they claim to, since they're potentially better suited for this than the existing use of GHashes.
---
Nope, Judy is slower:
% time perl -Mblib -MDevel::LeakTrace -e 'for (1..1000) {++$x}'
leaked SV(0x8140de0) from -e line 1
leaked SV(0x8140e1c) from -e line 1
perl -Mblib -MDevel::LeakTrace -e 'for (1..1000) {++$x}' 4.28s user 0.01s system 100% cpu 4.278 total
That and the API is weird.