James Paige wrote:
On Tue, Apr 06, 2010 at 06:03:29PM -0700, [email protected] wrote:
pkmnfrk
2010-04-06 18:03:29 -0700 (Tue, 06 Apr 2010)
411
Reworking reloadtest.bas into a unit test of the key features of RELOAD
(creating documents, navigating documents, serializing and deserializing trees,
etc).
Also, minor optimization in the Node type, by sticking ->num and ->flo in a Union
together, since only one of those is valid at any given time (depending on ->nodeType).
I would have stuck ->str in there too, but for some reason, FB doesn't like that.
---
U wip/reload.bi
U wip/reloadtest.bas
This is great, thank you!
As of two revisions ago, you also get timing information! On my system,
it looks like:
Test #1: createDocument... Pass
Took 2 µs
Test #2: addRootNode... Pass
Took 33 µs
Test #3: addSmallInteger... Pass
Took 9 µs
Test #4: addLargeInteger... Pass
Took 4 µs
Test #5: addFloat... Pass
Took 10 µs
Test #6: addString... Pass
Took 22 µs
Test #7: addEmpty... Pass
Took 7 µs
Test #8: addNested... Pass
Took 210 µs
Test #9: helperFunctions... Pass
Took 125 µs
Test #10: serializeXML...
<root>
*snip*
</root>
Pass
Took 71 ms
Test #11: writeFile... Pass
Took 11 ms
Test #12: loadFile... Pass
Took 1 ms
Test #13: compareDocuments... Pass
Took 8 µs
Test #14: freeDocument... Pass
Took 42 µs
Actually, this is a bit surprising. For some reason, writing the
document to disk is always considerably slower than reading from disk.
Probably because of all the string table searches... Fortunately,
loading is much faster, and when I implement delay loading, this time
will generally be very quick indeed (at the expense of future tree
navigation, of course...)
--
Mike
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
