Size of libinn (was: Re: INNT overview..)
rra at stanford.edu
Thu Jun 21 10:25:10 UTC 2001
Whew, now with that over with or at least well-started, I can get back to
some other INN stuff and old mail. :)
Fabien Tassin <fta at sofaraway.org> writes:
> According to Russ Allbery:
>> Fabien Tassin <fta at sofaraway.org> writes:
>>> I don't like libinn in its current form. I really would like to see
>>> smaller libs with dedicated sets of tasks.
>> Could you let me know what about it you don't like in particular? I'd
>> really like to clean up libinn as much as I can; there are parts of it
>> (sometimes large parts) that I haven't gotten to yet, but I think most
>> of the new stuff that's been put in or cleaned up is pretty solid and
>> generally useful.
> It is mainly a size problem.
> -r-xr-xr-x 1 news news 1236736 Mar 7 00:11 libinn.a
> -r-xr-xr-x 1 news news 692554 Mar 7 00:11 libstorage.a
> the threading problem is also easier to avoid/fix with much smaller libs.
Much of the size problem is relatively localized, actually:
windlord:~/dvl/inn/lib> ls -lrS *.o | tail -15
-rw-r--r-- 1 eagle root 4528 Jun 21 03:14 vector.o
-rw-r--r-- 1 eagle root 4552 Jun 21 03:14 wildmat.o
-rw-r--r-- 1 eagle root 4768 Jun 21 03:14 getmodaddr.o
-rw-r--r-- 1 eagle root 5292 Jun 21 03:14 error.o
-rw-r--r-- 1 eagle root 5656 Jun 21 03:14 date.o
-rw-r--r-- 1 eagle root 5996 Jun 21 03:14 timer.o
-rw-r--r-- 1 eagle root 6048 Jun 21 03:14 hashtab.o
-rw-r--r-- 1 eagle root 8440 Jun 21 03:14 inndcomm.o
-rw-r--r-- 1 eagle root 12080 Jun 21 03:14 md5.o
-rw-r--r-- 1 eagle root 12136 Jun 21 03:13 snprintf.o
-rw-r--r-- 1 eagle root 15528 Jun 21 03:14 dbz.o
-rw-r--r-- 1 eagle root 17668 Jun 21 03:14 perl.o
-rw-r--r-- 1 eagle root 18700 Jun 21 03:14 confparse.o
-rw-r--r-- 1 eagle root 22608 Jun 21 03:14 parsedate.o
-rw-r--r-- 1 eagle root 79892 Jun 21 03:14 getconfig.o
As you can see, far and away the worst offender is the current inn.conf
parsing code, in part because the current implementation involves code
duplication on a massive scale. The new parsing code should be a
significant improvement there.
parsedate is the second-worst because yacc is a bloated hog. I'm pretty
sure that there are better ways of doing date parsing that doesn't require
a full-blown parser, particularly since it's questionable whether we
really want to allow some of the stuff that parsedate allows through.
Of the rest, dbz is going to move into the history library once we land
that code, perl.o isn't included in libinn.a, snprintf isn't included if
you have a working version, and pretty much everything else other than the
configuration parsing code is noise.
It's true that a lot of it isn't thread-safe, but then again most of it
you'll never call.
>> How does it conflict with dmalloc? Maybe I can help resolve the
>> conflict? My intention was for xmalloc to be more generally useful
>> than even just in INN, and I have an interest in making sure it doesn't
>> have serious conflicts with other packages.
> dmalloc already uses xmalloc defines..
> dmalloc.h :
> #undef xmalloc
> #define xmalloc(size) \
> _xmalloc_leap(__FILE__, __LINE__, size)
> #undef xcalloc
> #define xcalloc(count, size) \
> _xcalloc_leap(__FILE__, __LINE__, count, size)
What's wrong with that? Provided that you include dmalloc.h last as it
recommends, it will just undefine and redefine the xmalloc, xcalloc,
etc. functions and use dmalloc's error handling for allocation failures
rather than INN's. Given that this is for doing debugging, that doesn't
seem like it would cause any harm.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers