|
01:19
Pixi__ joined
01:23
Pixi` left
02:18
Pixi joined
02:20
Pixi__ left
06:41
JRaspass left
06:42
JRaspass joined
06:52
ab5tract left
06:56
ab5tract joined
13:31
[Tux] left
14:20
[Tux] joined
|
|||||||||||||||||||||||||||||||||||||||
| [Tux] |
|
14:44 | |||||||||||||||||||||||||||||||||||||
| tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log | |||||||||||||||||||||||||||||||||||||||
|
20:57
MasterDuke joined
|
|||||||||||||||||||||||||||||||||||||||
| MasterDuke | ugexe: i wondered if your slow Version code was a problem with Version, but no. it's just creating all the strings and then joining them that takes the time | 21:00 | |||||||||||||||||||||||||||||||||||||
| tellable6 | 2025-08-04T20:07:20Z #raku-dev <ab5tract> MasterDuke: I see that the missing bit (the part that's in Perl6/Grammar) mentions $*W, which isn't available in RakuAST | ||||||||||||||||||||||||||||||||||||||
| 2025-08-26T15:10:29Z #raku-dev <jdv> MasterDuke looks like some are yours | |||||||||||||||||||||||||||||||||||||||
| 2025-08-27T15:09:37Z #raku-dev <jdv> MasterDuke I reverted it. | |||||||||||||||||||||||||||||||||||||||
| ugexe | MasterDuke: it seems slow even when I slurp that large version in from a file | 21:04 | |||||||||||||||||||||||||||||||||||||
| MasterDuke | i wonder why MVM_STRING_MAX_STRANDS is 64? the string struct uses an MVMuint16 to store the number of strands | 21:05 | |||||||||||||||||||||||||||||||||||||
| ugexe | theoretically i could make an even longer version string and put that as a version, upload it to fez, and then slow down module installation on all systems regardless of what they are installing | ||||||||||||||||||||||||||||||||||||||
| MasterDuke | the string does have 78,888,897 chars... | 21:06 | |||||||||||||||||||||||||||||||||||||
| ugexe | the more general problem is parsing items from meta6.json that are needed to build a reasonably quick index/lookup | 21:08 | |||||||||||||||||||||||||||||||||||||
| MasterDuke | locally, your code as written takes 25s. if i add `.Str.chars` to it, it's 23s. but if i just print the string instead of creating a Version it still takes 16s. and just printing `.chars` of just the string takes 13s | 21:09 | |||||||||||||||||||||||||||||||||||||
| so yeah, the Version.new is slow. but i think it's just because processing a very large string is slow | 21:10 | ||||||||||||||||||||||||||||||||||||||
| ugexe | right | ||||||||||||||||||||||||||||||||||||||
| the namespace and auth don't need to get parsed so it doesn't really matter how long those fields are | 21:12 | ||||||||||||||||||||||||||||||||||||||
| api and version (both a Version) do | |||||||||||||||||||||||||||||||||||||||
|
21:13
tonyo left
|
|||||||||||||||||||||||||||||||||||||||
| ugexe | parsing something like semver would presumably be much less of a problem as well since i think the number of version parts is limited | 21:13 | |||||||||||||||||||||||||||||||||||||
| MasterDuke | well, even if they don't get "parsed", they still probably get read i | ||||||||||||||||||||||||||||||||||||||
|
21:13
tonyo joined
21:15
ugexe left
|
|||||||||||||||||||||||||||||||||||||||
| MasterDuke | but i think i agree with what you're getting at, rakudo/moarvm are more susceptible to DOSing via large strings than some other languages, since they do NFG | 21:15 | |||||||||||||||||||||||||||||||||||||
|
21:15
ugexe joined
|
|||||||||||||||||||||||||||||||||||||||
| MasterDuke | dinner & | 21:16 | |||||||||||||||||||||||||||||||||||||
| ugexe | i guess theoretically a version object could be somewhat lazy | ||||||||||||||||||||||||||||||||||||||
| like to do a comparison of v3.1.2.3.4.5.6 and v9.1.2.3.4.5.6.7 it really only needs to parse up to v3. and v9. | 21:17 | ||||||||||||||||||||||||||||||||||||||
| regardless, it would make sense for ecosystems in particular to enforce length limits to e.g. api and version | 21:19 | ||||||||||||||||||||||||||||||||||||||
|
21:20
MasterDuke left
|
|||||||||||||||||||||||||||||||||||||||