I understand that creating too many threads in an application isn’t being what you might call a ‘good neighbour’ to other running processes, since cpu and memory resources are consumed even if these threads are in an efficient sleeping state.
What I’m interested in is this: How much memory (win32 platform) is being consumed by a sleeping thread?
Theoretically, I’d assume somewhere in the region of 1mb (since this is the default stack size), but I’m pretty sure it’s less than this, but I’m not sure why.
Any help on this will be appreciated.
(The reason I’m asking is that I’m considering introducing a thread-pool, and I’d like to understand how much memory I can save by creating a pool of 5 threads, compared to 20 manually created threads)
I have a server application which is heavy in thread usage, it uses a configurable thread pool which is set up by the customer, and in at least one site it has 1000+ threads, and when started up it uses only 50 MB. The reason is that Windows reserves 1MB for the stack (it maps its address space), but it is not necessarily allocated in the physical memory, only a smaller part of it. If the stack grows more than that a page fault is generated and more physical memory is allocated. I don’t know what the initial allocation is, but I would assume it’s equal to the page granularity of the system (usually 64 KB). Of course, the thread would also use a little more memory for other things when created (TLS, TSS, etc), but my guess for the total would be about 200 KB. And bear in mind that any memory that is not frequently used would be unloaded by the virtual memory manager.