These are useful as well (from the maker of the module):
mastodon.xyz/@gdad_s_river/99053872795281329
github.com/nolanlawson/tiny-queue/issues/1
Also this:
Background: I've a non CS background, so no CS101 knowledge at all.
Why is tiny-queue's shift method (github.com/nolanlawson/tiny-queue/blob/master/ind…) faster than native array shift, as told in the readme of the module?
The less code you use, the less there is to break
These are useful as well (from the maker of the module):
mastodon.xyz/@gdad_s_river/99053872795281329
github.com/nolanlawson/tiny-queue/issues/1
Also this:
Jason Knight
Because it's for all intents and purposes a pointer based nodelist, not an array. A more complete implementation each element would have more properties. The parent queue would have 'first' and 'last', whilst each sub-node would have 'previous' and 'next'. Same as how HTML elements on the DOM have firstChild, lastChild, previousSibling, and nextSibling.
With a pointered list you can just point to the last one, pull it's previous sibling, unset it, set that previous sibling's "next" to null and set "last' to that sibling.
Whilst JavaScript arrays do not actively track the last item -- or any indexes really. That's part of why JavaScript arrays are so AGONIZINGLY slow is that on every access MOST engines walk the entire list of pointers just to find the index you are after, hence the longer the array the longer the operation takes.
A problem we wouldn't have if JavaScript had typecasting and didn't automatically re-order the arrays if you unset a middle index.
... and why the new typed arrays are much, MUCH faster at this sort of thing.