|
🦋 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 |
22:38 | |
|
23:09
sena_kun left
23:24
sena_kun joined
23:26
sena_kun left
|
|||