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

[Benjamin]

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.

Would Subsurface ever support saturation diving? If so, wouldn't that
mm[:']ss become rather unwieldy/annoying due to it's high resolution? :)



On 27 September 2013 09:07, Henrik Brautaset Aronsen <
subsurface at henrik.synth.no> wrote:

> On Fri, Sep 27, 2013 at 7:39 AM, Benjamin <nystire at gmail.com> wrote:
>
>> Is the compression going to be at the file level or at the dive level?
>>
>> This may be a heretic's question, but given the fact that the information
>> will be compressed, is there any real advantage to dropping the XML
>> formatting? After all, it seems the only change is for the saved data file
>> itself, and in RAM there will be no real changes to how the data is stored.
>>
>
> My guess is that it will be zipped.  There's no reason to do it per dive.
>
> Another thing regarding the timestamps on each sample.  I prefer "mm:ss"
> instead of "mm'ss", since some editors and text viewers are trying to color
> encode stuff in between quotes.
>
> Henrik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130927/d9b07e46/attachment.html>