Media Library Performance

Media Library Performance & Optimization Improvements

The winners so far:

• Use guid instead of media_item_id for sort disambiguator - 1
• Use jemalloc as our allocator - 2
• Use media_item_id as a foreign key in resource_properties rather than guid - 3
• Maintain database tables of distinct values for some properties - 3
• Sort rows in memory when possible - 2
• Create sbGUID and sbGUIDHashKey - 2

Performance on 0.5

Performance with bug 8247 fixed:

Other candidates:

P	Bug Description	Cost	Objective
1	Share guid array instances between clients with the same sort/filter/search configuration	2
1	Optimize guid arrays for newly blank items	2
1	Long delay/hard drive thrashing on first application run after Windows restart	3
1	Add interleave reader support	1
1	Enable and test cost/benefit of SQLite fulltext search	1
1	"vacuum" the metadatajob database on job completion	1
1	Need some kind of object cache w/ expiration policy	3
1	Smart(er) cache sizing	1
1	Promote oft-used properties to media_items table	3
1	Include album+track in sortable data for artists	3
1	Enumerate* calls are done synchronously so the user interface "freezes"	3+
1	Use jemalloc as our allocator	3+
1	Slow start up	3
1	use atoms for property compares	3
1	Maintain database tables of distinct values for some properties	3
1	Maintain a distinct value table for all properties	3
1	Issue only single notifications for multi-item operations	3
1	Use media_item_id as a foreign key in resource_properties rather than guid	3

Q) Are we going to support legacy profiles for 0.6? Do we need a migration script? 

A) Daniel said no - we are a small startup with a product with not many users. We plan to make more changes to DB as we see fit between now and mass-launch.