The width of the textarea after pressing reply is too large. 
The problem is that the algorithm that searches for the longes line
looks for the next '\r' which it does not find and therefore takes the
number of characters in the text to be the width of the longest line.
To search for '\n' instead should solve the problem.  Please find the 
diff output below.


$ diff -c elogd.c elogd.c~
*** elogd.c     Mon Aug  4 13:57:35 2003
--- elogd.c~    Fri Aug  1 13:13:09 2003
***************
*** 6028,6035 ****
      p = text;
      do
        {
!       /*      pend = strchr(p, '\r'); */
!       pend = strchr(p, '\n');
        if (pend == NULL)
          pend = p+strlen(p);
  
--- 6028,6034 ----
      p = text;
      do
        {
!       pend = strchr(p, '\r');
        if (pend == NULL)
          pend = p+strlen(p);
  

> The width of the textarea after pressing reply is too large. 
> The problem is that the algorithm that searches for the longes line
> looks for the next '\r' which it does not find and therefore takes the
> number of characters in the text to be the width of the longest line.
> To search for '\n' instead should solve the problem.  Please find the 
> diff output below.

Ok, implemented, thanks.

> Boolean attributes were not displayed correctly in version 2.3.9.
> Patch is attached.

Yes, implemented, thank you.

This is not really a bug, but elogd was getting really slow with our
logbook.  It took about 4 1/2 seconds just to get the default page in
threaded mode with 15 entries.  The logbook has in total about 2000
entries, though.

After playing around with the compiler option '-gp' and gprof the
problem was found: loc() is called about 18000 times per logbook
access!  (Attached you can find the gprof output.  There might be
other places where to save time: e.g. getcfg().)  The function loc()
calls stat every time to check if the language file was updated and
this takes a long time especially over NFS.

The quick solution for me was to just replace loc() with 'char
*loc(char *orig) {return orig;}'.  Therefore, I cannot use the
localization that I used anymore, which is not a big problem at the
moment.  After that the time to download the default page was only
0.16 s; almost a factor of 30 faster!

I would suggest to only read the language file (AND also the config
file!) once upon startup.  After changing things one has to restart
elogd, which is not so nice, but the long delay is not acceptable.
Another option not to restart elogd is to make elogd respond to a
signal (e.g. kill -HUP) to reread the config and language files.

This is a very nice measurement you made and helps me a lot. I will 
incorporte your suggestions into the next version. Under Windows however, 
there is no -HUP signal, so that won't work for them. But what I can easily 
do is to check for new configuration/language file once every access, not 
once every loc() or getcfg(). I till think about.

Thanks again,

  Stefan

I implemented the new scheme where 

- under Windows, the configuration is only checked once every access

- under Unix, the configuration is read initially, and on every -HUP signal

This should speed up the server considerably. The next bottleneck is the 
rsputs2() function, which requires quite some computing power in order to find 
any "http://", "//", etc. strings in every output. If anybody knows a 
more clever way of coding that, please let me know.

The new version is under CVS.

> I implemented the new scheme where 
> 
> - under Windows, the configuration is only checked once every access
> 
> - under Unix, the configuration is read initially, and on every -HUP signal
> 
> This should speed up the server considerably. The next bottleneck is the 
> rsputs2() function, which requires quite some computing power in order to find 
> any "http://", "//", etc. strings in every output. If anybody knows a 
> more clever way of coding that, please let me know.
> 
> The new version is under CVS.

may be use the logic in the 'format' attribute
like 'email', http, ftp 
so elog will test only on these attributes

Elog is a great program, but it can be slow.

I noticed that the gcc compiler options in the tarball Makefile were not
conducive to speed.  There, I tried changing the gcc options to:

CFLAGS = -O3 -funroll-loops -fomit-frame-pointer -W -Wall

for version 2.5.3, the compile worked, and the program appears to work as
normal, but a bit faster.   I have not benchmarked it, but I think it should
offer a nominal increase in speed.

In particular, I removed the "-g" profiling option, which is not needed for
production code, and can be safely removed. In addition, I put in slightly
aggressive optimization settings, so if this doesn't work for you, you can
first try removing the -f setting, and then backing off the optimization to -O2.

Other may want to post other settings that work for them.