Date: Thu, 22 Jul 1999 07:32:15 +1000 From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> To: hackers@FreeBSD.ORG Subject: Re: speed of file(1) Message-ID: <99Jul22.071350est.40331@border.alcanet.com.au> In-Reply-To: <3795B50B.EFBBEFE2@isocor.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
I wrote: > Looking at ktrace with MALLOC_OPTIONS=U, it does do a lot of > realloc()ing (once for every 20 active lines in .../magic) and sbrk()s > to a maximum size of ~390KB - not really significant. and in a later message: > When I profile file in a slow system (like a 386 or 486), there is an > obvious performance bottleneck: The problem is the memcpy() invoked > from fgets(). Peter Edwards <peter.edwards@isocor.ie> wrote: >A MAXMAGIS constant in file.h that estimates a limit of 1000 lines in >magic. (The real number is 4802) > >An array sized on MAXMAGIS, that is reallocated every ALLOC_INTR lines >of magic once MAXMAGIS is exceeded. That'll teach me to rely on the output from gprof. I thought that gprof's claim (repeated by me) that the apprentice_1() -> fgets() -> memcpy() chain was taking all the time looked dubious, but it was consistent across several systems (and it was late at night for me). (Anyone want to adapt the profiling code so that it correctly apportions time between callers, rather than just using number of calls?) My earlier statement about lots of realloc's, together with the (accurate) datapoint that memcpy() was very slow should have led me to Peter Edwards fix. It also explains why the 3.2/4.x magic file (which has only about 20% more lines) takes 50% longer to start up (continually reallocing to increase an array size is O(N^2)). Congratulations to Peter Edwards. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Jul22.071350est.40331>