Jeremy Allison jallison at
Fri Jul 31 16:13:44 GMT 1998

Richard Sharpe wrote:

> 1. Create a new source file, files.c
> 2. Move all code that handles the Files and FileFD structures into this
> source file.

No please don't do this.

> 3. Provide access routines that provide access to paramenters in an object
> oriented manner
> 4. Get rid of macros from header files that access Files directly.

Andrew Tridgell wrote:

> looks great.
> > This has a performance implication. Now, instead of CHECK_READ accessing
> > Files[fnum].can_read, a function call will be made to can_read_file(fnum)
> > or some such function.
> I doubt this will be peformance critical, as long as the current loops
> over the Files[] array are moved completely into files.c

I disagree.

The performace hit will be *very* large (cumulatively)
by changing these macros to functions.

The Files structure is accessed *everwhere*. IMHO It is not
practical in terms of performace to move access macros 
out into a separate file accessed only by functions.
The Files[] macros are probably used more than the
DEBUG macro over all the code.

I have been going through as I work in a file changing
occurrences of Files[fnum].field_name to an initial
load of a pointer (fsp) followed by fsp->field_name
in circumstances where there is more than one access
into Files[fnum]. Poor or register starved compilers 
can generate terrible code given the former.

As an example - look at the new nttrans.c code - especially
the new directory checks for entries in the Files struct.
This accesses many parts of the Files structure. It would
be a *massive* pain to re-write everything here.

I would agree with moving the management of the allocation
etc. of these structures into a separate file, but not the
wholesale replacement of all accesses into the structure
with functions.


Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.

More information about the samba-technical mailing list