On 2/4/06, Jessie Hernandez <[EMAIL PROTECTED]> wrote:
> Hi Andrei,
>
> Pardon me for my ignorance, as I have not even looked at the Unicode
> stuff, but based on what you wrote, what about always allocating two
> UChars per codepoint? It would take a bit more space, but then
> random-offset indexi
Hi Andrei,
Pardon me for my ignorance, as I have not even looked at the Unicode
stuff, but based on what you wrote, what about always allocating two
UChars per codepoint? It would take a bit more space, but then
random-offset indexing is fast and easy (the codepoint would always
start at "ind
First of all I was simply proposing a very generic concept without
bothering about the implementation on purpose. If it's not feasible then
simply ignore it.
Marcus Boerger wrote:
caching? There is nothing to cache. And even if we would do that we would
make every string an object since we w
Hello Christian,
caching? There is nothing to cache. And even if we would do that we would
make every string an object since we would need to invalidate the position
cache on write operations. Also i agree with the others that most common
usage would be accessing a few chars probably changing th
Cache it where? In the zval or the opcode? What if the string changes?
How do you detect that and invalidate the cached position?
-Andrei
On Feb 2, 2006, at 5:19 PM, Christian Schneider wrote:
You could cache the last position (PHP- and Unicode string index) and
start from there. This assumes
Andrei Zmievski wrote:
I am not sure how we can optimize [] to be faster than the iterator
approach. Food for thought?
You could cache the last position (PHP- and Unicode string index) and
start from there. This assumes that most accesses are (more or less)
sequential. If you can step backwar
