> lob> #8 Each subdirectory should have one C file that includes
> lob> the 'modules' other C files (much like the crypto.c/ssl.c)
> lob> but for each directory. I failed to compile crypto.c,
> lob> was too large :(.
>
> Why use crypto.c or ssl.c at all? I've never quite understood the
> monolith philosophy around those files. And from what I see in the
> Makefile.ssl's, they aren't generally used anywhere (no, I haven't
> looked at the building on other architectures... Except VMS, where I
> have promptly tossed the monolith building).
>
> I do not really see what you mean by performance either. Are you
> talking about compiler/linker performance? I don't really see the
> importance in that, I'd assume the performance of the application you
> build at the end would be more important, and perhaps as well the
> size, and in such a case (which is what I personally prefer), you gain
> more by having a library with a gazillion object files to pick from
> than by having a library with a low number of huge object files.
>
I am not talking about compiler/linker performance, in fact using
a one-file-per-module-build makes the build take even longer due
to the increased size of the compiler scope. But that's where the
target performance benefit kicks in. Having all functions in the
same file so to speak and making all the non-api ones static enhances
the optimization possibilities for the compiler. It can inline
etc. Compiling small sections of a module separately limits the
optimization possibilites. I am not a compiler expert so I can
only speak for my own embedded experiences with 'one-file'
compiles increasing the performance of a module by up to 10%. I am
using compilers like MRI, GHS, DIAB, armcc and the above may have
lesser effect on the well used gcc.
Also, spending much of my time reading map files finding or
scouting for possible problems I kind of like the idea of
less public symbols. Ideally, only API symbols should be
exported from a library, and no internal functions or data.
This will lessen the chances for name-space collisions. Use
of hundreds of C files makes the above kind of hard to realize
though.
Either way, it was just an idea for increased performance that
could be worth trying. I do not propose getting rid of the
multiple file solution just yet since on the other side of the
table is always the decreased code-size.
Lennart Bang
TCP/IP knudel
[EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
