Store element data (e.g. _private) in an in-memory DB

[maxkfranz]

Benefits

• Core could probably handle more elements without slowing down
• Continuous mappers wouldn't need to be managed by the core anymore (easily query new min/max on renderer side)
• Getting elements by selectors would be faster
• Selector logic is simplified -- just translate a selector string into a DB query
• A collection is just a DB view -- a subset of the entire DB
• Allows for sorting of collections

Options

• TaffyDB http://taffydb.com/
• XBSDB http://xbsdb.org/

TaffyDB is probably the best option, but we'd have to test to see if it works for objects as values. Otherwise, we'll need multiple tables.

[maxkfranz]

This may not actually give us any speed improvements https://docs.google.com/spreadsheet/ccc?key=0Avnke0Xj5rgddDRaaUJZRkNLM0tiVURUc0JiWF9lOVE&hl=en#gid=4

[maxkfranz]

What may be more worthwhile is including performance tests in our unit tests for

• adding new elements sequentially
• loading a large json graph
• searching for elements with a selector / filter function

[maxkfranz]

This may be worthwhile eventually, since the pool of elements becomes slow for add and remove operations when the number of elements becomes large: Adding 100,000 elements to the graph can take about 6-7 seconds.

[maxkfranz]

Browser support for databases is still spotty, and now with WebSQL being dropped, it doesn't look like this will be possible without something like this https://github.com/kripken/sql.js

[maxkfranz]

Not practical for synchronous operations; closing