James Mansion wrote:
Mark Mielke wrote:
I recall there being a measurable performance difference between the
most liberal parser, and the most optimized parser, back when I wrote
one for PostgreSQL. I don't know how good the one in use for
PostgreSQL 8.3 is. As to whether the cost is noticeable to people or
not - that depends on what they are doing. The problem is that a UUID
is pretty big, and parsing it liberally means a loop.
It just seems odd - I would have thought one would use re2c or ragel
to generate something and the performance would essentially be O[n] on
the input length in characters - using either a collection of allowed
forms or an engine that normalises case and discards the '-'
characters between any hex pairs.
Instruction level parallelism allows for multiple hex values to be
processed in parallel, whereas a loop relies on branch prediction and
speculative load and store? :-)
The liberal version is difficult to unroll. The strict version is easy
to unroll.
So yes these would have a control loop. Is that so bad?
Either way its hard to imagine how parsing a string of this length
could create a measurable performance issue compared to what will
happen with the value post parse.
I think so too.
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
