Re: double _close()?

[Gisle Vanem]

Bruno Haible wrote:

> I added this __try/__catch uses because
>    - POSIX wants an error return rather than a program crash for
>      calls like close(-1).
>    - We make extensive use of such calls in the test suite.
>
> If you find, by extensive testing, that SANE_LIBRARY_HANDLING works
> for your programs, you can of course enable it.
>
> However, that will not bring a significant performance benefit,
> since installing a handler is cheap. It's the actual response to
> an exception (with stack unwinding) that's expensive; but at this
> point you will already have verified that no such exception is
> being generated.
>
> The actual performance improvement comes with the patches you
> propose to eliminate the exceptions.

Hello Bruno.

Many thanks for explaining this.

> > Does this make sense?
>
> It would make sense for the fclose at the end of a program.
>
> However, in general, a 'FILE' object often holds a buffer, and
> fclose(fp) is supposed to free that buffer, even if fd is already
> closed. Thus, skipping the fclose_nothrow call introduces a memory leak.

Right. But I'd rather have leaks than a lot of exceptions.

So a 'diff -r dir1 dir2' is using mostly read() and
close(). Changing to:
 MSVC_INVALID_PARAMETER_HANDLING == HAIRY_LIBRARY_HANDLING

and counting number of 'rpl_flose()' calls and 'fclose_nothrow()'
catches, I find only 2 (no matter how many files I'm diffing).

I'm just trying to speed-up GNU-diff; using 'Process Explorer',
I find that the read-rate is 300 kByte/s on average (with some
peaks at ~5 MByte/s) and CPU < 1%. IMHO this is patheticly slow.

I've been trying several things to speed it up:
 1) SetPriorityClass (GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
 2) Hinting the Windows-cache manager with a 'O_SEQUENTIAL'
    in open (file, O_RDONLY | O_SEQUENTIAL, 0);

Neither helps much. I'm not sure there's anything Gnulib
can do about this. Maybe a memory-mapped I/O in GNU-diff
could improve the speed?

--
--gv