I'll concede that splice, as currently implemented, is O(N) (much as I hate to say that).
That said, splice, shift, and unshift could all become O(1) if the following were to happen:
- Whenever a shift happens, that space is kept at the front of the array and the internal starting point gets moved. (This already happens, I believe).
- Whenever a mutation is made that would force a reshuffle, instead a pointer is made to another area (kind of like an arrayref). This would mean that bookkeeping would have to be instituted so that the memory location can be found in the case of a random access. I haven't written this bookkeeping code, but my gut says that it's not too squirrelly. This would work for both unshift and splice.
- In the case of a normal interaction with the array, no shuffling would occur, so this would just entail a single extra check into the bookkeeping data structure to determine that there is no special bookkeeping.
I suppose I could write up a Tie::Array that would do this. In thinking about it, this may sound like a proper solution for DBM::Deep's arrays. What do you think?
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
I don't believe that bookkeeping would work very well. I think with very many inserts you'd quickly end up with nothing more than a linked list that wastes a a lot of memory.
But I would honestly be delighted if you could prove me wrong. I'm not completely sure I'm right, I just haven't been able to come up with an algorithm in my head that would really make sense. I mean, I am wrong a lot, an awful lot of the time, but I'm going out on a limb here and saying there's no way you can implement that random access linked list you're talking about there. It would be squirrelly as all get-out, and it would quickly devolve into a mess where the accesses are indeed O(n).
So I dare you to try and implement an example.
| [reply] |