Replies: 3 comments 5 replies
-
If it's just a wrapper to an immutable JS string, CL code can be much slower because every mutation now has to copy the entire string. Imagine setting characters or pushing characters to the string in a loop, for example.
Could be. The most effective way is probably to implement a proper rope data structure. But I think the current implementation is fine. I don't have evidence this is the bottleneck for anything as of now. |
Beta Was this translation helpful? Give feedback.
-
But that is not a very common operation, isn't it? JS strings are internally very complicated in JS implementations, already using ropes and different representations. When you concatenate large strings you do not necessarily allocate a bigger one with a copy. We would have to measure but I think string concatenation, comparison, substring and such, are probably more common and should be faster. |
Beta Was this translation helpful? Give feedback.
-
|
From https://iliazeus.lol/articles/js-string-optimizations-en/:
|
Beta Was this translation helpful? Give feedback.
-
|
These makes sense. But I still think it's asking for trouble. Consider making a string with |
Beta Was this translation helpful? Give feedback.
-
|
Run a little experiment and go some benchmark numbers with LLM. Not reviewed. Influenced by bad designs in the compiler right now too (as we do concat a lot more than with-output-to-string, etc). Also, I did this without support for fill pointers, which are cases where vector representation would be better. I still find this appealing though. I might be biased because I worked last on the FFI system, and it would make clstring and jsstring very very cheap. I think it's worth doing some more serious experiment. Also if we use classes and provide compatible methods. We could easily have both representations, and pick one of the other depending on the presence of fill-pointer, etc. MicroMicrobenchmark Results: Baseline vs Before Optimization vs After Optimization Optimization = using JS primitive functions to reimplement things like reverse, subseq, etc. JSCL Compiling itself and tests |
Beta Was this translation helpful? Give feedback.
-
|
The slowdown from "baseline" to "before opt" is what I was worried about. Yes, for standard CL string functions, we can do "after opt". But users are going to run pure CL string manipulating libraries/programs in JSCL, which might become much slower. I think two representation is too much complexity and still won't solve it. Presence of fill pointer is not a reliable way to tell if user will want to do lots of mutation (potentially in the middle). When will we fallback to vector? And when a string becomes vector, there're no benefit in |
Beta Was this translation helpful? Give feedback.
-
|
Most of the deops are still faster. But I wouldn't read much into the numbers until I test something more manually.
I'll find some benchmark. But I honestly doubt it. JS engines are so optimized. I've never seen anyone working with strings as vectors. But I'll do some more careful experiment and find some heavy benchmarking. |
Beta Was this translation helpful? Give feedback.
-
|
And some |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
A idea I'm not sure if it's good, but right now we implement strings as a vector of characters. What if we changed this to be reprsented as an object containing the Js string? like
This would make the JS-FFI conversion cheaper. Would it make CL code faster too? a vector of strings sound pretty effective too, unless we're doing a bad job.
This still supports mutability (the reason why CL strings aren't just JS strings)
We might make sequence.lisp functions a bit worse as a string is not that similar to a vector anymore.
Beta Was this translation helpful? Give feedback.
All reactions