Open boxbeam opened 1 year ago
this is done and an optimization was added to increase the performance of modifying strings by updating the cached version of the string as well but this could cause a performance hit in some scenarios so we should do some bench-marking to see if this is a good idea or not
since this is a further and technically unnecessary optimization I believe we can leave it to after the beta launch as more of a improving the language steps rather than just creating the initial version of it
possible solutions are:
I feel like we should go with either the first or third and then if we go with the third say something in the docs that the default form should only be used in the repl or maybe personal scripts and that any code that gets shared should use the specific forms to maintain performance
this might also make no difference and its just faster to never do it in which case im putting too much thought into this thing that I am saying we shouldn't think about right now anyway
I think storing strings strictly as Vec<char>
with no other representation will be the best long term solution. It would also allow us to create a substring type so you could get a substring of a string in O(1). I would be willing to help (re)write functions to support this.
Well with the current implementation and the potential optimization you can do that
cause the strings are just a Vec
the optimization I am talking about is if the cached string is up to date and another string or character gets appended then it will also append the character to the cached rust string
the more I think about it the more ways I can see for optimizing it in different ways and for prioritizing different things, like compute time vs memory. So I wanna say push off trying to do all these now so we can get a better idea of what will be usable and work best in real scenarios during the beta. So for now lets just either have the cached string get updated when quickly possible or just remove it for now and just have it get dropped when the cached string is de-synced. Then at a later time after evaluating it in the real world we can decide if that was the right call, or if the cached string should just not exist at all, or if you should have to specify if you want to have one or not when creating the string so that short and constantly reprinted strings can be cached; but longer, and constantly being modified strings will just never cache their printable forms.
actually having the caching be an optional opt in thing sounds like a good idea to just implement now if you agree
Our current string type uses a rust string, which can't be indexed by character. We should switch to a string type which holds a
Vec<char>
.