Re: CopyReadLineText optimization revisited

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