I am kind of an efficiency freak myself. But on a Linux box, if you
open, write, read, close, delete /tmp files in a loop, I don't think
you see any physical disk I/O other than a 1 block directory update
every minute or so.
I totally agree that the C function is more elegant, but I've also
learned that elegance can by highly overrated. If it's very important
that this particular micro thing be blazingly efficient, then do it
the right way. But if you have to invent more code to get a very
insignificant performance boost (in the grand scheme of things), then
it may not be worthwhile. Most of the cost is not in the initial
development of it, but rather in the maintenance and future
consideration of it when making other changes. If you are increasing
the size of the code base without making a very significant
contribution, then it's probably not worthwhile, IMO.
The way I approach these things is to do a prototype in TCL using
existing interfaces/functions, develop the whole application/page that
will use it, and THEN if there is a performance problem, make sure
that this thingy is the cause. Most of the time the bottleneck is
not in something as low-level as reading the post data, but in loops,
searching, DB queries, etc.
Where we have found very HUGE bottlenecks are in using TCL string
functions on large strings. TCL passes everything by value, so you
end up copying this huge string (like 300K) every time it is
referenced. A real performance killer.
(We are still using the crusty 2.3.3... I know, I know... :)
Jim
>
> On 2001.07.21, Mike Hoegeman <[EMAIL PROTECTED]> wrote:
> > I was doing the above but it's a bit heavy handed don't you think?
> > considering the data in question is usually less than 500 bytes.
>
> If ns_tmpnam is generating a filename in /tmp, and your /tmp is
> a mount in tmpfs and you have plenty of RAM, then going from
> socket to file in tmp is actually quite fast -- I bet even some
> platforms could do a readv() straight from socket fd to filesystem
> fd without entering into userspace, or do some other kind of
> mmap'ing deal.
>
> Of course, now sucking the file back from the fs in /tmp into
> your userspace application might suck, but again, if it's in
> tmpfs, it'll be way fast.
>
> -- Dossy
>
> --
> Dossy Shiobara mail: [EMAIL PROTECTED]
> Panoptic Computer Network web: http://www.panoptic.com/
>
