Re: performance implications of releasing resources and context switches

On Jul 28, 8:33 am, Ambrose Silk <si...@xxxxxxxxxxxxxx> wrote:

It seems there might be a performance benefit to forgoing the munmap()
and close() calls and letting them be handled by _exit() instead. As I
read the docs, _exit() is a single system call (thus 1 context switch)
which guarantees to remove all mappings, close all open files, etc.

If your process is long-running, you have to clean up as you go along.
Otherwise, you risk tying up or running out of resources. So you can
only do this for resources that you would normally free right at the
end of your execution.

Normally speeding up the end of execution wouldn't have any
significant benefit. The performance you care about is performance
while you have work to do, not after all your work is done.

A typical process might allocate a resource 1,000,000 times in its
life and need to free 995,000 of them while it's running. So at most
there's that .5% that you could let the exit implicitly free. And
that's the .5% that you only free when you're done with what you were
doing anyway, so it's the .5% that has the least impact on
performance.

It's like Federal Express trying to rush their employees home at the
end of their shifts. Sure, it saves a bit of employee time, but it
doesn't get the packages delivered any faster. Longer shifts are a
better solution to cutting the overhead of shift changes.

DS
.

Relevant Pages

  • Re: Python style guidelines
    ... It's that "resources acquired" part that messes people up. ... and then doesn't find all the subsequent exit points. ... Yep, those guidelines are useless. ...
    (comp.lang.python)
  • Re: Unexpected exit of pthread
    ... keep resources around even when functions return. ... TSD with a destructor. ... The only STANDARD ways defined by the POSIX STANDARD that a THREAD can exit are pthread_exit except in the initial thread where it's exit) and delivery of a cancellation request to the thread. ... POSIX once considered a "pthread_abort" interface that would force immediate termination of another thread; and while it was rejected by POSIX any vendor might choose to implement something like that. ...
    (comp.programming.threads)
  • Re: proper way to daemonize
    ... On Apr 24, 2009, at 12:11 PM, James Gray wrote: ... as it will call all "at_exit" handlers in the ... What resources are you talking about? ... By the time exit is called, ...
    (comp.lang.ruby)
  • Re: performance implications of releasing resources and context switches
    ... Ambrose Silk wrote: ... and closecalls and letting them be handled by _exit() instead. ... you risk tying up or running out of resources. ... of the program using mmap/munmap and about 1.3 seconds ...
    (comp.unix.programmer)
  • Re: performance implications of releasing resources and context switches
    ... and closecalls and letting them be handled by _exit() instead. ... you risk tying up or running out of resources. ... The core of what it does is checksumming files. ... Now, why there are ~6K extra mmap calls and only ~2K extra munmaps, and ~5K more opens vs ~8K more closes, is a very interesting question which I'm looking into. ...
    (comp.unix.programmer)