Geth MoarVM/main: 5b48ae1e53 | (Daniel Green)++ | src/6model/reprs/NFA.c
Remove some unused code

Looks like it was missed in 6941cada41a2ae2f32eb6ae179d41053468304f1.
00:16
00:17 MasterDuke joined
Geth MoarVM/main: f2220d93d9 | (Daniel Green)++ | src/core/coerce.h
Increase the size of the int-to-str cache to 65

This means we will cache 64, which was coerced ~42k times during a Rakudo build. A micro-benchmark (`my int $i = 64; my $s; $s = ~$i for
  ^10_000_000; say now - INIT now; say $s`) decreased from ~0.50s to
  ~0.22s.
00:26
00:44 japhb left 00:45 japhb joined 01:31 MasterDuke left
Woodi s/64/65/ is funny :) make me thinking: do calculating in-memory tables (compile/build time) of every possible conversions for 1..100 (and maybe other things) would speedup something ;) 08:54
but maybe it's just profiled compilation subset 08:55
09:17 lizmat_ joined 10:19 lizmat__ joined 10:22 lizmat_ left 12:41 lizmat_ joined, lizmat__ left 13:05 lizmat_ left, lizmat_ joined 13:10 lizmat_ left 13:11 lizmat_ joined 13:51 lizmat_ left, lizmat_ joined 14:08 lizmat_ left 17:42 MasterDuke joined 18:03 kjp left
MasterDuke jnthn: since i've only had minimal success speeding up runAlt on the jvm backend, i started looking at the script that gets run during that`+++ GeneratingĀ  gen/<backend>/ast.nqp` stage 18:15
even for the moarvm backend 90% of the time is spent in run_alt 18:16
parsing ~25k lines in 35 files in 12s 18:17
github.com/rakudo/rakudo/blob/main...qp#L71-L87 is where in the script it spends the most time
do you have any quick-and-easy suggestions to speed that (the script in its entirety or just that part) up? 18:18
nine lizmat: binding attributes is not atomic after all. Since attribute objects are inlined into their parents when you bind to an attribute, the full object gets copied which leaves a window open for race conditions. 19:32
lizmat argh...
nine Binding to locals or lexicals is atomic as that's just updating a pointer 19:33
22:13 kjp joined