in reply to Re: Speeding up unshift
in thread Speeding up unshift
Because I am trying for obvious correctness in the patch first. I wanted to make the code be exactly like it would have been under the old (ie tested) logic if more elements had been asked to be added to the beginnning of the array. So the patch was, "Increase the request, drop the excess elements." Conceptually simple, obviously correct. That said AvFILLp(av) probably shouldn't be adjusted twice in a row. OTOH it is possible that smart compilers will figure that out, and compared to the cost of the copy...
And what is AvMAX()?!
AvMAX() is the maximum number of elements the array can have before it needs to be reallocated. Every time you adjust the location of the start of the array you need to adjust it. Personally I think that this is an unfortunate and confusing design decision.
And I would personally suggest using the heuristic for slide that I had in my code...
I considered it, then thought about it. If you try to build up a very large array with one huge unshift, your heuristic forces that array to take a lot more space than it needs. The patch will optimize many small calls to unshift, not a few big ones. If there are many then deciding to add a lot of extra space the second time rather than the first is not a big deal. Think of it as just being lazy on deciding that you need a lot of buffering. :-)
BTW I am still thinking about it. Even though in terms of what finally happens adjusting AvFILL twice is clearly stupid, in terms of conceptual units for someone looking at the code, it simplifies what is going on. I don't think that the change is worth making. (In case you are interested to get the accounting straight I just glanced at what shift did to verify what was going on, then copied in reverse the accounting logic straight from the earlier logic where you had space to work with.)
|
|---|