Timeline for Does immutability hurt performance in JavaScript?
Current License: CC BY-SA 3.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 14, 2019 at 19:05 | comment | added | Sal Rahman |
From my experience, if you're updating a single property of an object the immutable way (Object.assign or object rest spread), you're effectively copying all properties to the new object. This is an O(n) operation. Also, if you are truly a functional purist, and you want to update all fields, using Object.assign or object rest spread for each individual fields, then you will get O(n^2) operation.
|
|
| Feb 2, 2017 at 12:48 | history | protected | gnat | ||
| Jan 5, 2017 at 15:15 | comment | added | T. Sar | Keep in mind that Immutability is not a miracle silver bullet. As several other trending aspects of software development - like dependency injection, agile methodologies, microservices, and several design patterns - it is a single tool on a giant set of tools that a dev has at hand. Use it only if it is the right tool for the job. | |
| Jan 2, 2017 at 22:30 | comment | added | semicolon |
@RobertHarvey One particularly impressive data structure to look at is Haskell's Data.Sequence (finger trees). It's fully persistent so all operations completely preserve the old copy. Yet it's asymptotics are better than arrays for almost every operation. append / prepend / pop / leftpop are O(1), concatenation is O(log(min(n, m))), inserting / deleting / adjusting / splitting is O(log(min(i, n - i))), tails / inits are O(n). So as long as you go far enough with immutability to make pervasive sharing safe, you can get some serious performance gains.
|
|
| Jan 2, 2017 at 22:22 | comment | added | semicolon |
@RobertHarvey "Immutability, all by itself, only has performance benefits in the sense that it makes it easier to write multi-threaded code." That is not entirely true, immutability allows for very pervasive sharing with no real consequences. Which is very unsafe in a mutable environment. This gives you thinks like O(1) array slicing and O(log n) inserting into a binary tree while still being able to use the old one freely, and another example is tails which takes all the tails of a list tails [1, 2] = [[1, 2], [2], []] only takes O(n) time and space, but is O(n^2) in element count
|
|
| Jan 5, 2016 at 18:29 | audit | Suggested edits | |||
| Jan 5, 2016 at 18:29 | |||||
| Dec 25, 2015 at 2:35 | answer | added | user204677 | timeline score: 39 | |
| Dec 10, 2015 at 13:40 | vote | accept | callum | ||
| Dec 9, 2015 at 17:53 | comment | added | djechlin | tldr yes but the entire programming community is moving toward this for the blunt reason that concurrent programming bugs are more expensive than copy objects. | |
| Dec 9, 2015 at 15:32 | comment | added | JAB |
@Katana314 At least it wasn't O(pow(2, n)).
|
|
| Dec 9, 2015 at 13:28 | comment | added | seldon | Returning a new object doesn't necessarily mean duplicating its content | |
| Dec 9, 2015 at 10:53 | answer | added | Dan | timeline score: 5 | |
| Dec 9, 2015 at 3:58 | answer | added | Dogs | timeline score: 4 | |
| Dec 9, 2015 at 3:00 | comment | added | slebetman | @Katana314: 30+ times for me would still not be enough to justify worrying about performance. I ported a small CPU emulator I wrote to node.js and node executed the virtual CPU at around 20MHz (that's 20 million times per second). So I'd only worry about performance if I were doing something 1000+ times per second (even then, I wouldn't really worry until I do 1000000 operations per second because I know I can comfortably do more than 10 of them at once). | |
| Dec 9, 2015 at 1:58 | answer | added | Bringer128 | timeline score: 12 | |
| Dec 8, 2015 at 18:05 | answer | added | Karl Bielefeldt | timeline score: 42 | |
| Dec 8, 2015 at 17:50 | history | tweeted | twitter.com/StackProgrammer/status/674285018311753728 | ||
| Dec 8, 2015 at 16:32 | comment | added | Giorgio | Also, consider that there exist efficient implementations of immutable data structures. Maybe these are not as efficient as mutable ones, but probably still more efficient than a naive implementation. See e.g. Purely Functional Data Structures by Chris Okasaki | |
| Dec 8, 2015 at 16:23 | comment | added | Katana314 |
In my experience, performance is only a valid concern for two scenarios - one, when an action is performed 30+ times in one second, and two - when its effects increase with each execution (Windows XP once found a bug where Windows Update time took O(pow(n, 2)) for every update in its history.) Most other code is an immediate response to an event; a click, API request, or similar, and as long as execution time is constant, the cleanup of any number of objects hardly matters.
|
|
| Dec 8, 2015 at 16:22 | comment | added | Mason Wheeler | @RobertHarvey has it right. Immutability inherently hurts performance, in JavaScript or anywhere else. It can be useful for other reasons, though. | |
| Dec 8, 2015 at 15:48 | answer | added | Doc Brown | timeline score: 62 | |
| Dec 8, 2015 at 15:26 | comment | added | Doc Brown | See here: quora.com/… | |
| Dec 8, 2015 at 15:20 | comment | added | Robert Harvey | They have a strong concern for performance in part because immutability (sometimes) has a performance cost, and they want to minimize that performance cost as much as possible. Immutability, all by itself, only has performance benefits in the sense that it makes it easier to write multi-threaded code. | |
| Dec 8, 2015 at 15:01 | history | edited | gnat |
edited tags
|
|
| Dec 8, 2015 at 15:00 | comment | added | gnat | related: Performance of single-assignment ADT oriented code on modern CPUs | |
| Dec 8, 2015 at 14:58 | history | asked | callum | CC BY-SA 3.0 |