|
02:12
vrurg left,
vrurg joined
07:35
Geth joined
08:53
evalable6 left
08:54
quotable6 left,
committable6 left
08:57
evalable6 joined,
committable6 joined
08:59
quotable6 joined
09:16
librasteve_ joined
09:41
lizmat_ left
09:42
lizmat joined
12:16
librasteve_ left
|
|||
| Geth | MoarVM/main: 8 commits pushed by Faye++, (Elizabeth Mattijsen)++
|
16:40 | |
| lizmat | looks like Stage parse dropped about .5 second for me | 16:46 | |
| [Coke] | nice. | 17:03 | |
| timo | that's a surprise | 17:13 | |
| ShimmerFairy | If I had to guess why the parse stage dropped (and it's a total guess), maybe calling the boundary-finding function once per grapheme, rather than once per string position, reduced some function call overhead. | 17:18 | |
| timo | oh, does the time taken to decode the input file actually land in the timing for stage parse? i guess that makes sense | 17:19 | |
| ShimmerFairy | I'd guess so, since the only thing beforehand is "stage start", which I'm guessing is just "the program's started". | 17:27 | |
| timo | when i run `perf record -F10000 -g rakudo -e '"gen/moar/CORE.c.setting".IO.slurp.chars.say'` i get 8.92% time spent in MVM_string_utf8_decode and children, and a total 0.131048554 seconds time elapsed | 17:50 | |
| it would be quite a feat for stage parse to drop .5 seconds from just faster utf8 decoding if the performance on my machine is in any way representative of what liz's computer does? | 17:52 | ||
| lizmat | hmmm... well... maybe I was too enthusiastic : next Stage parse was at 25.0 (before 24.2) so I guess there's a bit of noise there | 17:54 | |
| timo | yeah, that's always a concern | ||
|
23:23
librasteve_ joined
|
|||