[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: double _close()?

From: Gisle Vanem
Subject: Re: double _close()?
Date: Thu, 14 Oct 2021 12:47:50 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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:

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]