Lists Home |
Date Index |
On Wednesday 26 February 2003 16:06, Bill de hÓra wrote:
> So, following David, in one hundred secs, you spend one second
> parsing XML and 99 seconds doing somehting else. Suppose you get a
> tenfold speedup doing something else (cigars all round). You're down
> to 11 seconds. Parsing is approaching 10%. A tenfold speedup in
> parsing only saves you 1/2 a second, or approaching 9%, now. And
> because it's /still/ the wrong side of the 80/20 split, it's /still/
> not place to be looking, unless you know that processing time is
> evenly distributed through the code base (but that would be rare,
> and probably worth writing a paper on). The same reasoning applies
> at 10% time to begin with.
*waving arms in air and trying to get noticed*
A 50% reduction in the size of exchanged messages will, in a bandwidth
limited situation such as the Internet, double the number of concurrent
connections you can be handling, and double the number of messages you can
move in a given time period!
Not to mention that a format that deals with string termination by putting a
length integer in front of the string rather than at the end is a godsend in
a tiny embedded system since you can just allocate a buffer for that many
bytes and read it in, or seek that many bytes ahead if you just want to get
past the string, rather than having to build up the string in preallocated
blocks while keeping a tally of the length so you can copy it to a single
span of memory afterwards, etc.
> I'd like to see some some numbers on parsing concerns, so we could
> figure out a) is there a problem, b) where is a problem, c) what's
> the solution.
Binary data encodings that compare with XML seem to quote being able to
reduce the size of the data to 20%-50% of the original size. Happy? :-)
> Bill de hÓra
A city is like a large, complex, rabbit