Re: cvs commit: src/sys/kern imgact_elf.c init_main.c kern_checkpoint.c kern_descrip.c kern_event.c sys_generic.c sys_pipe.c uipc_syscalls.c uipc_usrreq.c vfs_aio.c vfs_syscalls.c src/sys/sys filedesc.h src/sys/dev/misc/streams streams.c ...

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Wed, Jun 22, 2005 at 10:38:30AM -0700, Matthew Dillon wrote:
> 
> :
> :On Wed, Jun 22, 2005 at 01:13:01PM +0200, Simon 'corecode' Schubert wrote:
> :> Lately Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx> said:
> :> >   Log:
> :> >   File descriptor cleanup stage 2, remove the separate arrays for file
> :> >   pointers, fileflags, and allocation counts and replace the mess with a
> :> >   single structural array.  Also revamp the code that checks whether the
> :> >   file descriptor array is built-in or allocated.
> :> 
> :> can anybody enlighten me why this was done in the first place?
> :> this way it's much clearer anyways
> :
> :But it is also slower because the amount of data which has to be copied when
> :the array is extended is now doubled. (pointer vs. struct fdnode)
> :
> :Joerg
> 
>     Lets quantify slower.
> 
>     Bytes per entry (before):	9	(three separate arrays)
>     Bytes per entry (after):	16	(one array of fdnodes)
> 
>     Linear copy rate:	1 gigabyte sec
> 
>     Do I need to continue and calculate how many nanoseconds longer
>     it takes to do something that isn't in the critical path?

I know, I don't complain at all :) This was just explain why the original
code was choosen. Beside, on slower processors we are talking about a lot
more nanoseconds, but it still doesn't matter at all.

Joerg