>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 _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
