On Mon, Dec 04, 2000 at 03:17:00PM -0800, Adam Haberlach wrote:
> Typically (on a well-written OS, at least), the spawning of a thread
> is much cheaper then the creation of a new process (via fork()).
Unless I'm mistaken, the back-end is only forked when starting a new
connection, in which case the latency of doing the initial TCP tri-state
and start-up queries is much larger than any process creation cost. On
Linux 2.2.16 on a 500MHz PIII, I can do the fork/exit/wait sequence in
about 164us. On the same server, I can make/break a PostgreSQL
connection in about 19,000us (with 0% CPU idle, about 30% CPU system).
Even if we can manage to get a thread for free, and assume that the fork
from postmaster takes more than 164us, it won't make a big difference
once the other latencies are worked out.
> Also, since everything in a group of threads (I'll call 'em a team)
Actually, you call them a process. That is the textbook definition.
> shares the
> same address space, there can be some memory overhead savings.
Only slightly. All of the executable and libraries should already be
shared, as will all non-modified data. If the data is modified by the
threads, you'll need seperate copies for each thread anyways, so the net
difference is small.
I'm not denying there would be a difference. Compared to seperate
processes, threads are more efficient. Doing a context switch between
threads means there is no PTE invalidations, which makes them quicker
than between processes. Creation would be a bit faster due to just
linking in the VM to a new thread rather than marking it all as COW.
The memory savings would come from reduced fragmentation of the modified
data (if you have 1 byte modified on each of 100 pages, the thread would
grow by a few K, compared to 400K for processes). I'm simply arguing
that the differences don't appear to be significant compared to the
other costs involved.
--
Bruce Guenter <bruceg@em.ca> http://em.ca/~bruceg/