From: David Abrahams (dave_at_[hidden])
Date: 2005-10-05 09:06:30
Rene Rivera <grafik.list_at_[hidden]> writes:
> Rene Rivera wrote:
>> 10100 910 540 0.053465 20413007 2021
>> 1. Create a native buffer functionality for which the memory can be
>> manually managed. This would allow some strings to move out of the cache
>> and be allowed to be freed soon after they are no longer needed. The
>> "print" functionality would make use of this. As so would any CAT like
>> builtin. It might be possible to make header scanning also use this.
>> This is not a real savings in memory use, just on lowering the impact on
>> other string use.
> Now that I've though about it a bit more and looked at code bit more; A
> more useful feature would be to implement a native FILE object
> interface. One that can both read and write to the files. This would
> allow implementation of the RC files, which is what takes up room now,
> without any need to hold on to the strings in memory. And without the
> need to do the platform quoting for "echo" which is what multiples the
> number of strings created in this case.
I just want to make sure that none of these optimizations contort the
design of BB too much, since (I hope!) right after BBv2 replaces v1
(when??!) we'll be replacing the guts with Python.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk