On 17 September 2010 16:11, Mike Caron <[email protected]> wrote: > On 9/17/2010 12:01 AM, Ralph Versteegen wrote: >> >> On 17 September 2010 15:46, Mike Caron<[email protected]> wrote: >>> >>> On 9/16/2010 11:43 PM, [email protected] wrote: >>>> >>>> teeemcee >>>> 2010-09-16 20:43:54 -0700 (Thu, 16 Sep 2010) >>>> 372 >>>> Last minute change to the zonemap file format: switch to a span-based >>>> format (as already documented on the Wiki) >>>> >>>> This format is easier to write, but surprising slower to read and write >>>> (about half), and the file size is now mostly RELOAD overhead (wish Mike >>>> hadn't rejected my suggestions for better space efficiency). >>> >>> Which ones were those? :S >> >> -Use a VLI instead of an INT for node size. Even if you reserve 4 >> bytes whenever the node has any children, and then write the size >> later, you can probably use a single byte for leaf nodes. > > Except, the reason I use four bytes is because: > > 1. It's very difficult to "slide" the rest of the file over to get rid of > the extra space. Even if that were easy, > 2. It would create a cascading effect on the sizes of all other nodes.
You misunderstood. I meant: if the node has no children, determining the size is easy; otherwise reserve 4 bytes (27 bits: 134MB) and come back and write the VLI later. > Both those problems would be solved if we rendered the file into memory > first, but I'm not particularly enthused about writing this code. We do already write the file to memory first, but of course it's not designed to do this. >> -Add a bit to the type byte that indicates whether or not there are >> any children, so that you can skip the VLI for number of children for >> leaves. > > This is reasonable, since I don't foresee having to add any new types. You'd still be able to have up to 128 types. >>> Those reduce the overhead from 7 bytes per leaf to 3. So if the >>> average size of a .Z 'spans' data node is 3 bytes (guessing), it's a >>> significant saving. >> >> I forgot that strings also have a size VLI, so it's actually 8 vs. 4. > > I agree that it's significant. > > An alternative, however, might be to forgo the size counts entirely. The > reason they exist is to allow efficient scanning of the file in cases where > you only care about part of the file. However, this is impossible with the > current API, so... Huh? The sizes are used to skip over nodes when using delay loading. Wasn't that exactly their intention? And that seems worth keeping. Another option would be to only include the sizes if the node has children, but that's getting a bit messy. > Proposal: Bump the version to 2 and omit the size parameters entirely. > Thoughts? I figured we would eventually create a new version, and that I would not let my suggestions be excluded again; however there's no hurry to do so now. I guess it's it wouldn't be much work though. >>>> Also finally added zonemap support to map resizing. >>>> --- >>>> U wip/loading.bas >>>> U wip/loading.bi >>>> U wip/mapsubs.bas >> >> _______________________________________________ >> Ohrrpgce mailing list >> [email protected] >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
