New file format [was: CPU hogging in the current master]

[Dirk Hohndel]

The in memory representation per dive (simply the data structures on the C side, I have not looked into the Qt/C++ overhead) is actually relatively small. Switching between dives would become unbearably slow if we had to seek on disk, uncompress, parse and then display the data. Especially when you do things like Ctrl-A and click on the statistics tab… you need to load all dives for that, anyway.

/D

On Sep 27, 2013, at 7:15 AM, Benjamin wrote:

> (Embedded systems programmer warning!) Does it not make sense to only ready the needed parts of the data file into memory as the file grows larger? Or will Subsurface always work on the assumption that there is enough memory available to store the entire, parsed data file? Or am I completely off track?
> 
> 
> On 27 September 2013 17:10, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
> On Sep 26, 2013, at 11:14 PM, Benjamin wrote:
> 
> > If the whole file is compressed, that would mean uncompressing the entire file itself in order to load specific records from it. If the records were compressed, then we could have (in theory - need to find that paper about searching for compressed data...) much faster access to the individual records within the data file with the slight trade-off of a larger data file.
> 
> Since the data will be uncompressed as you read the file and will then reside in memory, I see no advantage of compressing on a per record basis.
> 
> > Would Subsurface ever support saturation diving? If so, wouldn't that mm[:']ss become rather unwieldy/annoying due to it's high resolution? :)
> 
> We have no interest in supporting saturation diving. On the flip side, many of us have DCs with 5s resolution - some are even configurable to do less. So there's ample justification for mm:ss format.
> 
> /D
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130927/30d8de88/attachment.html>