On Feb 10, 2013, at 9:33 AM, JOSE MANUEL CANTERA FONSECA wrote: > El 09/02/13 00:55, "David Flanagan" <[email protected]> escribió: > > I think we should push forward indexedDB performance improvements instead > of ad-hoc custom home-made solutions. The problem with approaches like > those you are describing is that every different app will end up defining > its own mechanisms. If indexedDB perf cannot be improved maybe managing > this kind of app data R/W files, can be abstracted by a library to be used > by different apps.
Optimization beyond the 80% case is always an app-specific exercise. No doubt indexDB performance can be improved, but it won't be the right solution for all problems. I'm willing to state that media for example should be always saved directly to disk (even thumbnails). Flatfiles are a perfect good solution for situations where reading performance is paramount, datasets are relatively small and updates are rare. The first half of my career was data processing, including design, implementation and operations of the entire logging and processing system for a very large early search engine company. We always used flatfiles. I spent a year researching various "next generation" database options... and went back to using flat-files. Nothing else came close for performance and storage density. To be clear, I'm not arguing against framework abstractions, but boilerplate & frameworks will rarely get you past the 80% threshold. I think this discussion needs to happen because we can't individually keep reinventing the wheel. Its clear basic performance patterns are not currently well understood across the board. For example, email seems to take forever loading what seems like my entire inbox. What's the most common use-case for an email app? Probably open, scan the last 5-10 new emails, maybe reply to one, and close again. We should optimize for that via incremental loading with read-ahead. Read only the first two to five pages worth of data, and more as the user starts scrolling to keep ahead of the view. We don't need to keep loading if the user isn't scrolling. Even if the view sometimes has to catch up, its a better optimization than wasting battery, memory and the user's time loading a ton of data. 99% of which the user will not look at. These are patterns that other mobile platforms have already built in, and we are reinventing them from scratch unfortunately. For each app this will be slightly different though, depending on the database access patterns and type of data stored. This is why David Flanagan's and Kyle's experiments of determining performance impact of different patterns are important. We should understand break-even points between using cursors, using getAll() for loading chunks (X to Y rows at a time), and loading the entire dataset. Sometimes getting the entire dataset from indexdb in one request makes the most sense, when that data is of a small bound size and tends to change often (i.e. a top 10 list). OTOH, atomic data that needs to be read quickly but never changes has no place in a database. >> >> With both IndexedDB and DeviceStorage, I've attempted to start the db >> opening process or the file reading process in a non-deferred script >> that is loaded first. This is in the hopes that by the time the document >> all the deferredscripts are loaded and I get a DOMContentLoaded, I'll >> have an open db waiting for queries, or I will have received my file >> from device storage. In practice, though, it appears that loading the >> document and its scripts take priority and that attempting to start my >> I/O earlier doesn't make things substantially faster. > > Interesting, here we would need information from Gecko Platform people. A useful pattern here can be breaking up your app into multiple iframes and not having everything hanging off the top level window. For one thing, it allows for better garbage collection as the iframes get periodically flushed, but also it means you don't have to block startup on loading tons of scripts. I think Andreas already brought this up, but really we probably should never have the top level window of an app contain anything more than a simple bootstrap and an iframe. In fact the top level window should probably never source any script, period. Lucas. _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
