Re: Huge execution time in 4.2, WAS: for; do; done regression ?

[Chet Ramey]

On 1/7/11 5:09 AM, Jan Schampera wrote:
> Alexander Tiurin wrote:
> 
>> ~$ time for i in `seq 0 10000`  ; do echo /o/23/4 | cut -d'/' -f2 ; done
>> > /dev/null 
> 
> To track this a bit, I ran the exact command several times in a Bash 3.2,
> seeing increasing execution times (40s up to ~2min), as reported.
> 
> I knew there were several bugs about filedescriptors and leaks fixed since
> then, so I tested it in 4.2 beta. The first run took about 27 minutes(!),
> the second run still goes on.
> 
> I can't imagine this is just some debugging code still active (it's a beta).

Imagine.  Anything that doesn't have a version tag of `release' has DEBUG
enabled for the preprocessor, which enables MALLOC_DEBUG.  If you're using
the bash malloc, MALLOC_DEBUG turns on extensive memory checking and
allocation tracing.  All active allocations are kept in a hash table with
8K entries, and when you fill up that hash table, each new allocation has
to search the entire table before throwing away an old entry.  That quickly
degenerates.  This can be fixed, but it hasn't become a priority yet.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/