Design Decisions

The purpose of this page is to document the changes made to the code and to explain the thought process for design decisions.

• JavaScript Generators are slow:
  https://strongloop.com/strongblog/how-to-generators-node-js-yield-use-cases/

• Mozilla Bookmark Observer -- might be a bug with Mozilla, but saw several observer events for a single change. Sorting was also triggering observer events. This resulted in looping and increased memory usage. Memory increase caused by cache for observer events during sorting.

• Tried using Worker (WebWorker/ChromeWorker/PromiseWorker). Not able to access chrome/Components. Was able to perform sorting in Worker, however, because Workers are only given a data-only copy of an object (methods not copied), had to perform setIndex() in main thread, which still caused blocking.

• To prevent blocking, make setTimeout() calls within for-loop; this gives browser time to do UI stuff. Like the following:

setTimeout((function(arg1){ return function(){ foo(arg1); }; }(bar)), 2000);

• Be careful what you remove -- there was code added for better performance on Windows. It got deleted because it made no difference on MacOS. Need to add comments for this type of code. While JavaScript runs on different platforms, keep in mind that the behavior may not be consistent on all platforms.

Older Design Decisions

• First, I do not use the places/bookmarks module from the Add-on SDK because it is too slow. I wrote my own bookmarks module instead.
• When a user has many bookmarks, it takes a lot of time to sort, so I made this choice to get a faster sorting.
• Besides, if you want to test this case (many bookmarks), I made a script to generate thousands of bookmarks. You can create a similar script (I wrote one in Rust and the other one in Haskell, you can find them here).