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

[Tomaz Canabrava]

The c++ overhead is something that I didn`t looked yet - but I`ll blindly
assume `not that much` unless I`m doing something shitty. :)



On Fri, Sep 27, 2013 at 11:30 AM, Dirk Hohndel <dirk at hohndel.org> wrote:

>
> 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
>>
>>
>
>
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130927/1ead32b7/attachment-0001.html>