Martijn van Oosterhout <kleptog@svana.org> writes:
> What follows is the detailed analysis of the change. My conclusion is
> that on Linux at least where the syscall overhead is so low, it's not
> worth the change for performance. It is cleaner code-wise IMHO.
How is it cleaner code-wise to debug and maintain two #ifdef'd code
paths instead of one? (And when I say "debug", I mean "I don't believe
FileSeek still works". One reason that the patch seems unmaintainable
to me as-is is that it creates a subtle, critical, and undocumented
difference in the semantic meaning of the seekPos variable: in one case
it's tracking the kernel's own seek position, and in the other it isn't.)
> What this tells me is that lseek time is swamped by actual read time,
> so not a major benefit in most cases.
It would be reasonable to check results in fully-cached cases, which
would be the best real-world scenario for this to show any improvement
in.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
