timo

for the second benchmark you posted, it's probably important to note that `@a := nqp::split(...)` will create a new array each go-around, which is probably a big chunk of allocations,...

on the other hand, if we have such a very small substring, it's also possible to decide "we should store the string in-situ instead of a rope-based substring" ... ok...

``` From e215e74bba2853cde0c9ddd53b1a1a424d860674 Mon Sep 17 00:00:00 2001 From: Timo Paulssen Date: Fri, 5 Jul 2024 22:31:16 +0200 Subject: [PATCH] fix comparison of strings involving in situ strings --- src/strings/ops.c...

do you know that the name exists in the dll for sure? maybe something changed somewhere. you should be able to use `dumpbin.exe /ALL D:\a\1\rakudo\13-cpp-mangling.dll` and `dumpbin.exe /ALL D:\a\1\rakudo\11-cpp.dll` and...

i don't have the brain power right now to actually look deeply at anything, but this looks kind of suspicious?  but probably just something you put in for debugging...

not sure if this does anything, but try `%lld` instead of `%ld` in the printf, maybe that's causing a problem?

yeah at least some of the numbers in the debug output are suspiciously 31 bits long and then a much longer number for the output of m and m2

yes, native-shaped-array performance is really weak at the moment.

i have tried to look into this and have gotten knee deep in what feels indistinguishable from untreated sewage and I have against my better judgement pushed beyond my frustration...

https://github.com/bytecodealliance/wasmtime/issues/291 probably related