Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x
От | Mark Mielke |
---|---|
Тема | Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x |
Дата | |
Msg-id | 47C7972B.1020202@mark.mielke.cc обсуждение исходный текст |
Ответ на | Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x (James Mansion <james@mansionfamily.plus.com>) |
Список | pgsql-hackers |
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 <mark@mielke.cc>
В списке pgsql-hackers по дате отправления: