Edit: We need a type system which makes O(n^2) algorithms illegal. (Yes... I know what I just dialed up. You can't see it, but I'm giving a very big ol' evil grin.)
For example, the find and replace package uses markers to highlight search results, and if you ran a search for the letter e in a large file, the excessive time spent updating thousands of markers on every keystroke was intolerable
This suggests another problem they have is a huge constant, in addition to the algorithmic one --- "thousands" shouldn't be something a modern machine would choke on, if updating positions is a simple operation like increasing their offset by 1 after a character is inserted. On a CPU that can do one billion instructions per second (a good OOM estimate, which still underestimates how fast real CPUs today are by a few times), adding 1 to 10000 variables should not take any perceptible amount of time --- less than a millisecond.
Going from 800ms to 50ms is a great improvement, but I think that's still several orders of magnitude slower than what the machine can really do.
As I mentioned in the article, a big part of the cost was updating a different interval storage structure as the markers were updated since the absolute positions approach left us no way to defer it.
"Extension" should probably be in scare quotes because the implementation is literally just CSS animation: https://github.com/dmnd/rainbow-selection/blob/master/styles...
There's no good reason such an animation should be taxing your machine. It works fine on my MacBook Pro. But someone else reported this issue too: https://github.com/dmnd/rainbow-selection/issues/3
If you're interested in working out what's going on, please respond to that github issue. I understand if you don't want to spend time on such a trivial thing. But you spent the time to write this comment, so I figured maybe you're interested :)
- written in 2014
but MDN now says:
> Column number for the line where the error occurred (number) - Requires Gecko 31.0
If anybody has live experience with this, I'm eager to hear about it.
It's always a little weird, because I have no performance issues anywhere else in it, and it's got ~7GB of RAM it could use.
I don't know what happened after that. Maybe they will act on this. The only problem with the O(n) engine was that a lot of TextMate grammars for languages wouldn't work with atom but that was easily resolvable by writing them anew.