the only memory that needs to be allocated (and that *should* be allocated) by charAt in particular is what is needed for the returned String object. If Strings are unique, then there should only be one such string per character at most, so it shouldn't be the cause for the high memory cost of parsing.
I agree that's how it should be. From memory, the way it works now is that charAt uses slice. the slice function converts the string to a charcode array (allocating an array). Then the relevant characters are extracted into a second array. Finally, a string is constructed from this... This allocates a string object, which we then lookup in the string table. If it's found in the string table, the one from the table is returned.
This could probably be optimized in at least two ways:
1. We could change the string code to directly read characters from string objects, eliminating the need for a char code array.
2. Instead of first allocating strings and then looking them up in the string table, it might be useful to have some kind of a system where we can write characters into a mutable buffer. When done, we can lookup the data from that buffer into the string table, and allocate a new string object only if its not found in the table. Ideally, the buffer would be kept alive (we could have a pointer to it in the context) between queries. It could have a fixed size that works well for common small strings (eg: 2KB). For bigger strings, we could allocate a bigger buffer and drop it afterwards.
I tend to avoid speculative optimizations like what you're proposing, just because they often end up wasting more resources than what is gained. How could we easily gather evidence to point us toward the most profitable optimizations? I'm not suggesting that string optimizations are not at fault (although I'd like to verify that as well), but if they are, we need to determine which ones are the most hurtful in terms of allocated memory.
Well, I'm not sure right now is necessarily the best time to do string optimizations. I'm guessing most of our time in the immediate future will go towards writing a GC. However, it probably wouldn't be so difficult to optimize most or all string functions in the way I just described.
- Maxime