[cad-linux-dev] Re: testing: intro
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: cad-linux-dev@xxxxxxxxxxxxx
- Date: Fri, 5 Dec 2003 19:05:33 -0600
> The following was supposedly scribed by
> cr88192
> on Friday 05 December 2003 06:00 pm:
>various reasons.
>you can do fancy stuff with binary formats (eg: straightforward incremental
>rewrites).
>parsing is very much simplified compared with text, and often can be done
>faster.
>eg: a tlv encoding can be used, often consisting of:
>read the tag;
>read the len;
>read the data (len bytes).
>
>the tag and data are then passed to a switch (or similar) construct, which
>may then decompose the data more or do whatever with it.
>
>with text one has to do things, eg:
>reading in a line (or otherwise managing buffering);
>reading tokens (ie: stepping along until whitespace is found or such);
>using string comparisons;
>
The question is whether your software needs that ~10% performance boost or
not. What sort of development speed do you anticipate? Will the format
change more frequently than the rest of the program? If you can totally
separate the file-format from the majority of your functions, you could
tackle the bulk of your development process while working under a textual
format and later switch to binary if you find that the textual format can
really not be made to run fast enough.
The thing which you will most gain from something straightforward and textual
is that debugging and testing can be done much more quickly if you can use
any old text tool to create/read/parse/transform some data.
We had a discussion on this list in October about using a broken-up version of
the YAML format. This was looking promising, since we would then be
leveraging the efforts of non-programmers (I think the discussion mainly
stopped at that point because we all got either busy or died (think I got a
case of the latter.))
I too have been leaning toward the directory-hierarchy based format where
files are stored in as atomic a form as possible. I've been putting this to
use quite a bit with my 3-million circles project and it has saved lots of
time in debugging.
If you are concerned about writing a parser, consider a parser generator such
as the yacc/ lex duo.
--Eric
--
Peer's Law: The solution to the problem changes the problem.
Other related posts:
