On Wed, Apr 3, 2013 at 6:25 PM, Roland Mainz <[email protected]> wrote: > On Tue, Apr 2, 2013 at 7:34 PM, Cedric Blancher > <[email protected]> wrote: >> On 22 September 2012 10:14, Cedric Blancher >> <[email protected]> wrote: >>> On 17 September 2012 00:15, Roland Mainz <[email protected]> wrote: >>>> * Issues: >>>> - We have to make sure that memory allocation doesn't get excessive >>>> - Currently it seems that the stream returned by |sftmp()| somehow >>>> causes the shell not to use |mmap()| to read the temporary file's >>>> (used if we spill over or call an external process) content even for >>>> "insanely" (in this context :-) ) large file sizes (e.g. 2^20 bytes) >>>> ... erm... what exactlly causes this ? >>> >>> BTW: mmap() is not used for ANY files on Fedora Linux with a 64bit >>> ksh93. I've just observed that shcomp munches a 100MB script via >>> read() and not mmap(), which is IMO unfortunate. >> >> Roland, I recall you have a test module to monitor the mmap() usage >> for sfio I/O. Can you contribute this to Glenn and David, please? > > Yes... but there are two issues: > 1. I have to dig-out the test modules from an old machine... may take a few > days > 2. Command substitutions still do not use |mmap()| ... as this example > with ast-ksh.2013-04-02 on SuSE 12.2 Linux/AMD64/64bit shows: > -- snip -- > $ strace ~/bin/ksh -c 'x=$(seq 400000) ; true' 2>&1 | fgrep 'read(' | wc -l > 50 > $ strace ~/bin/ksh -c 'x=$(seq 800000) ; true' 2>&1 | fgrep 'read(' | wc -l > 92 > $ strace ~/bin/ksh -c 'x=$(seq 1600000) ; true' 2>&1 | fgrep 'read(' | wc -l > 187 > -- snip -- > > Interesting question is... why does this happen ?
Erm... it seems the issue was simply "lost in time" ... or better: Forgotten. Again. Grrr... xx!!@@!! ... (which leads to my all-feared battle cry: "BUGZILLA!") ... Glenn... can you confirm this ? =:-) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
