DragonFly BSD
DragonFly commits List (threaded) for 2005-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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 ...


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 22 Jun 2005 10:38:30 -0700 (PDT)

:
: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?

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]