Re: still more 2.5.11 comments

[Bruce Lilly]

John Millaway wrote:
> > That depends on the system; older systems with slow disk
> > I/O will suffer considerably. 
>
>
> That remains to be seen. In the script below, I created a C file which
> #includes 1000 different flex generated header files, each 57 KB.  The compile
> time increases from 0.23s to 3.70s on a 466MHz. That's less than 4 milliseconds
> of compile time per flex header.
[...]

57 kB is a tiny fraction of the size of the header files that I
get from flex.  As 466 MHz machines are recent (within the past
4 years or so), that's a novel interpretation of "older systems".
And you have apparently failed to account for the presence of the
generated header files in the disk buffer cache.

Here's a quick test on a 3B1:

$ cat decl.h
/* for reentrant flex */
#define YY_EXTRA_TYPE struct parameters *
#ifndef FLEX_SCANNER
#define yyget_debug mailget_debug
#define yyset_debug mailset_debug
#define yyget_extra mailget_extra
#define yyset_extra mailset_extra
#define yyget_in mailget_in
#define yyset_in mailset_in
#define yyget_out mailget_out
#define yyset_out mailset_out
#define yyget_leng mailget_leng
#define yyget_text mailget_text
#define yyget_lineno mailget_lineno
#define yyset_lineno mailset_lineno
typedef void * yyscan_t;
extern char     *yyget_text(yyscan_t);
extern int      yyget_leng(yyscan_t);
extern FILE     *yyget_in(yyscan_t);
extern FILE     *yyget_out(yyscan_t);
extern int      yyget_lineno(yyscan_t);
extern int      yyget_debug(yyscan_t);
# ifdef YY_EXTRA_TYPE
extern YY_EXTRA_TYPE    yyget_extra(yyscan_t);
# endif
extern void     yyset_debug(int, yyscan_t);
extern void     yyset_in(FILE *, yyscan_t);
extern void     yyset_out(FILE *, yyscan_t);
extern void     yyset_lineno(int, yyscan_t);
# ifdef YY_EXTRA_TYPE
extern void     yyset_extra(YY_EXTRA_TYPE, yyscan_t);
# endif
#endif
$ cat foo.c
#include "decl.h"
#include "sc.h"
$ cat foo2.c
#include "mailflex.h"
#include "sc.h"
$ ls -l decl.h sc.h mailflex.h
-rw-rw-r--  1 root    root       1028 Aug 13 14:40 decl.h
-rw-rw-r--  1 root    root     522861 Aug 13 14:35 mailflex.h
-rw-rw-r--  1 root    root        635 Aug 13 14:35 sc.h
$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/3b1/2.5.8/specs
gcc version 2.5.8
$ time gcc -E foo.c > foo.i

real    0m2.63s
user    0m0.41s
sys     0m0.66s
$ time gcc -E foo2.c > foo2.i

real    0m22.33s
user    0m9.48s
sys     0m2.73s

Notes:
sc.h is the extracted start condition definitions
mailflex.h is generated by flex
as gcc -E was used, only preprocessing time is accounted for;
  subsequent compilation would involve larger output resulting
  from the extra stuff in the flex-generated header
It's possible that sc.h was still in the disk buffer cache when
  foo2.c was preprocessed -- but as foo2.c is the file which includes
  the huge flex-generated header, that could only *diminish* the
  effect of the flex-generated header size.

Note that real time has increased *per C file including the header*
  by an order of magnitude!  Or looking at absolute time, an
  additional 20 seconds per file.  So a project where 10 C files
  include the header would require more than an additional 3 minutes
  of preprocessing time due to the extra stuff in the flex-generated
  header file.

Best regards,
  Bruce Lilly