02:38 librasteve_ left 08:57 sena_kun joined
timo has anyone used Grammar::Debugger or Grammar::Tracer recently? 10:33
lizmat about a year ago, when I started the =rakudoc handling, why ? 10:47
did it bitrot?
notable6: weekly 10:48
notable6 lizmat, 1 note: 2024-12-10T12:59:58Z <antononcube>: rakuforprediction.wordpress.com/20...aku-set-3/
lizmat notable6: weekly reset
notable6 lizmat, Moved existing notes to “weekly_2024-12-23T10:48:43Z”
timo i'm not entirely sure. i seemed to recall it didn't work when i last tried it? two months ago or so maybe 10:49
lizmat It's a Raku Community module now 10:52
so go for it :-)
I can give you a zef upload bit if necessary 10:54
timo i kind of wish we had a common standard way for module authors to put benchmarks in their distros, maybe in xt/, for the purposes of measuring long-time changes in rakudo and moarvm performance 11:04
so we could do something similar to a blin run, but for benchmarks found in ecosystem modules 11:05
lizmat bt/ ? 11:06
timo .o( backtraces ) 11:07
lizmat I was thinking "benchmark tests" 11:12
timo what i'd like to see at the very least is standardised ways to handle setup and teardown, and a way to specify size of the "workload" to check how scaling behaves, and maybe a rough guideline to create essentially an estimation for what workload size corresponds to what run time. also it'd be important to consider multithreading and multi-processing in this, as well as necessary external
components. say, a postgres database has to be running in order to sensibly benchmark a postgres client library, i imagine
and we probably want to measure some performance counters instead of wallclock time, since other activity on the system that runs the benchmark can easily make timing data become worthless :) 11:31
lizmat in that respect I would love to see cpu time / thread metrics 11:33
timo most performance counters can be impacted by other stuff on the system; i think if there's more load, the program may be context-switched away more often, CPU caches evicted causing an increase in cache misses, stuff like that :| 11:35
i guess if we have to ensure whatever the "benchmark runner" is doesn't get distracted :) 11:36
then we can also use cpu time for measurement
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/12/23/2024-...-the-dots/ 11:57
patrickb I've used Grammar::Tracer recently when creating Rainbow. worked like a charm. 13:06
timo oh, ok that's good! 13:07