On Jan 21, 11:50 pm, Dominique Pellé <[email protected]> wrote: > > And graph after patch is here: > > http://dominique.pelle.free.fr/time-readfile.png
Thank you, an interesting tutorial. Next time I want to graph something I'll be searching for your post rather than firing up a spreadsheet. I can't help thinking that your linear times are not guaranteed with the vagaries of heap fragmentation and memory allocator implementation, and that calling into memory allocator code every 200 bytes of megabytes of data is to be avoided. Such intuitions are infamous, I suppose. I said: > > The old code's handling of allocation failures is haphazard, or at > > least I can't see a clear outcome if an allocation fails. > To test memory alloc failures, on Linux, you can limit the > the amount of virtual memory of the shell & its subprocesses... > with: ulimit -v <kbytes>. Thank you. Dominique said: > ... in my opinion, > when running out of memory, it's most of the time > hopeless to try to recover, except in few critical places. I agree, but that intuition says that if someone tries to do something really over the top with memory and it fails, we could give up on the big thing reliably. I'm thinking of the user on a limited platform, like DOS or even an iphone. Regards, John -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
