On 26/08/10 22:16, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>> * instead of the byte-at-a-time loop in CopyReadLineText(), use memchr()
>> to find the next NL/CR character. This is where the speedup comes from.
>
> That seems like the speedup, if any, would be extremely
> platform-dependent. What have you tested on?
Only on my 32-bit Intel Linux laptop.
If anyone out there has more interesting platforms to test on, that
would be appreciated.
>> There's a small fly in the ointment: the patch won't recognize backslash
>> followed by a linefeed as an escaped linefeed. I think we should simply
>> drop support for that.
>
> I think this is likely to break apps that have worked for years. I
> can't get excited about doing that in return for an "0-10%" speedup
> that might only materialize on some platforms. If the numbers were
> better, it'd be worth paying that price, but ...
Ok. If we have to, we can keep that, it just requires more programming.
After searching for a \n, we can peek at the previous byte to check if
it's a backslash (and if it is, the one before that to see if it's a
backslash too, and so forth until we find a non-backslash).
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com