🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
02:11 |Tux| left 02:24 |Tux| joined 05:57 [Coke] left 05:59 [Coke] joined 07:36 sena_kun joined 09:26 sena_kun left 09:28 sena_kun joined 09:29 sena_kun left 10:41 samcv left 10:42 samcv joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/12/11/2023-...ore-magic/ 13:02
13:20 sjn left 17:41 sjn joined
ab5tract I don't understand the performance degradation I'm seeing when running this code: gist.github.com/ab5tract/ff5373154...5fb0599c93 18:04
If it were GC issues, I'd expect periodic interruptions. What happens here is that performance is fine for the first 1-2cm of snowfall and then starts sliding off a cliff. 18:05
I've done several things to simplify and improve the code, including destructuring the objects into arrays of attributes. These arrays are kept from growing too large by splicing out snow that gets covered by a "fill line" in the snowfall accumulator. 18:07
18:39 sena_kun joined
ab5tract I was wrong about GC. It's definitely the culprit (avg. 71.9 ms), though it's unclear why it starts getting slower over time considering the code is designed to keep the amount of work per frame as clost to constant as possible. Does the GC even need to "collect" values that are thrown to the void in a splice call? 20:23
21:13 samebchase left, samebchase joined 21:14 samebchase left, samebchase joined, RakuIRCLogger left
Geth rakudo: vrurg++ created pull request #5493:
Complete generic instantiation 4
23:09 sena_kun left 23:24 sena_kun joined 23:26 sena_kun left