Re: [Nmh-workers] Limit of 27 messages sequences per folder

[Ken Hornstein]

>Apparently, nmh limits the number of message sequences per folder to
>5 less than the number of bits in a C int -- which, these days is
>usually 32. I guess 27 was once a large number, but perhaps, now, not
>so much. What would happen, to performance, on 64 bit machines if line
>86 of h/mh.h which now reads:
>
>       typedef unsigned int seqset_t;
>
>were changed to:
>
>       typedef unsigned long seqset_t;

Nowadays?  I doubt you'd notice anything.  I'm not sure that "unsigned long"
is guaranteed to be 64 bits on all newer platforms, though.  Hm.  It
looks like most Unix systems have gone to LP64 (which means that "long"
is 64 bits).  I suspect the original reasons weren't performance so
much as it was for memory conservation; every time a folder is read
the seqset_t array is allocated based on the size from the lowest message
number to the highest message number.  So if you had a folder with two
messages in it, "1" and "10001", you'd allocate 10000 * 4 bytes ... which
is slightly less than 40 kilobytes.  Upping that to 8 bytes per message
slot would make it approximately 80 kilobytes ... and that isn't exactly
going to bog your machine down :-)

>If there is no significant effect, then maybe int, vs long, for
>seqset_t, should be a made a configuration parameter ???

That would probably complicate things more than warranted. "long" is
a standard C type, and assuming we do everything right with sizeof(),
changing it should work.  The only challenge that comes to mind is that
if you have a sequence file with more than 27 sequences in it and you
use it with older nmh programs, what will happen?  Hm.  It looks like
it might silently ignore the "extra" sequence, which means that it would
get deleted from the sequence file if the older tool updated the
sequence file.

It seems to me that this change would be a good idea.  Thoughts from
others?

--Ken