Hacker News Reader

Comment by tedunangst | Hacker News Reader

"Nobody will ever echo this much data!"

It's actually not a bad suggestion

    #define BUF_INITIAL 1024
    char buf[BUF_INITIAL];
    
    int main(int argc, char** argv)
    {
        char* p;
        ...
        p = len > BUF_INITIAL ? malloc(len) : buf;
        ...
        write(1, p, len);
        ...
    }

djb's allocator alloc() does this. He preallocates a 4 KB static buffer before hitting system malloc(). Avoiding the overhead of malloc() is pretty important for the performance of systems like qmail that fork many small processes.

Many small processes? How many?

4 KB * (many) could be frightening.

If your system has 32,000 processes and you allocate 4 KB to each of them... that's 128 MB. I'm not crapping my pants at that figure because even the oldest machine in my office, an old Thinkpad, has 2 GB of RAM.

That's ridiculous. The overhead of fork is about a bajillion times higher than malloc.

Are you sure? I'd bet it's greater, I'd not bet that it's an order of magnitude better, fork() has been optimized a lot more than brk().

With a COW fork() I bet it's smaller. I smell a test coming on, but alas it's late here and I'm going to bed.

I'm also guessing that 4k was chosen because a malloc() of 1 page is faster than a malloc() of >1 page. Of course that's with the assumption that the systems use a 4k page size.

Oh wait they will

Reply on news.ycombinator.com