the parsing process is not inherently slow

[Eric Wilhelm]

# from Ovid
# on Tuesday 02 October 2007 02:50:

>Yes, that does parse TAP a heck of a lot faster.  It also parses a lot
>of things which aren't TAP.  In fact, it's so far removed from a TAP
>parser that I don't think it's anywhere close to a fair comparison.

I think it is an apt metric though.  Open a file, read each line, apply 
what is typically one regular expression to it.  I said it is 
an "oversimplification" because it obviously doesn't handle the entire 
TAP grammar.

>Speeding up the actual parsing is clearly a desirable goal, but that's
>orthogonal to the goal of having parallel test runs.  Each is useful
>independent of the other.

And yet, we seem to be designing the architecture around the assumption 
that the only way to speed-up the parser is with more cpu's.  This 
over-simplistic parser shaves about 97% off of the parse time, so my 
conservative guesstimate says we could probably get rid of 80% of the 
CPU spinning and still be a correct parser.  Even if we can only (very 
conservatively) cut 50% of the runtime, we have then matched dual-core 
parse speed without fork+IPC or threading.

So, the parser is not the bottleneck in real test suites anyway and the 
task of parsing is not *inherently* as slow as the current parser.

Even if an improved parser speed becomes a bottleneck (at around 900 
cores), we can deal with that in better ways than adding conditionals 
to the harness.

--Eric
-- 
"Time flies like an arrow, but fruit flies like a banana."
--Groucho Marx
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------