-
-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: LinkedList is in fact a Deque #222
base: master
Are you sure you want to change the base?
refactor: LinkedList is in fact a Deque #222
Conversation
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
…nto esm-support
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
…nto esm-support
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
A linked list API shall use a data structure as { data, next, prev} as a first class citizen. Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
closes Yomguithereal#218 Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
… linkedlist2deque Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
… linkedlist2deque
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
… linkedlist2deque
I agree with you. I have never seen the point of a dynamically sized Linked List in JavaScript and never had a use-case for it as it is never performant enough. Personally I am pondering to drop it altogether from the library. However, I would like to introduce fixed size singly & doubly linked lists like those used internally in some other structures of the library such as the lru cache because those are efficient and can be useful. I will personally need one soon to properly implement a Chiba-Nishizeki routine to count triangles in a graph. |
Happy to see you back. I hope it was because of holidays, not work :D
So, a roadmap:
sounds reasonable? |
Unfortunately it's work. This and I maintain a lot of Open Source libraries.
Why not, but I am not sure an actual linked list is the best implementation for a true unbounded Deque in JS. If I remember correctly the (I am only noticing now that you spoke about this in your comment here: "Optimize Deque implementation by using an array with two indexes start and end, or two arrays: benchmarks them") What I mean, in the end, is that I am not sure a lot of people are using mnemonist for the Linked List anyway and that it would probably not be very costly to trash it, even without a transition phase. I see the value in adding an unbounded Deque class in the library though.
I don't think we need a node class at all, because we can rely on representing them by numerical ids if the list is bounded. This is lighter and does not require allocation of node objects etc. It has some drawbacks because those ids are basically pointers that you can use to hurt yourself if you are not careful. |
It's not, but it's an intermediate step for introducing a fast unbounded Deque implementation.
The subsequent steps are indeed targeted at making the Deque implementation lean and fast using JS.
Do you have an example code of using such an optimisation? What will be the exact underlying storage data structure? I do not understand the trick here. |
…nto linkedlist2deque Signed-off-by: Jérôme Benoit <[email protected]>
Signed-off-by: Jérôme Benoit <[email protected]>
Rationales:
LinkedList
is not what is expected for an API dedicated at manipulating linked list node or link data structure:{ data, prev, next }
LinkedList
API is what is expected for an API dedicated to non boundedDeque
, except the missingpop()
opLinkedList
in javascript is not really performant. Not sure it's worth the effort in the end at implementing them via a clean API making node or link a first class citizenDeque
implementation backward compatible withLinkedList
is likely more useful to mnemonist usersChangelog:
LinkedList
related files toDeque
related filesLinkedList
importationDeque
API to theFixedDeque
API: deprecatefirst()
,last()
,peek()
ops, addpeekFirst()
,peekLast()
pop()
op by using a doubly linked listTodo:
Deque
implementation by using an array with two indexes start and end, or two arrays: benchmarks themDeque
andFixedDeque