From: David Abrahams (dave_at_[hidden])
Date: 2004-06-26 13:19:48
Vladimir Prus <ghost_at_[hidden]> writes:
> David Abrahams wrote:
>> >> I think that strategically, we better implement core features in a
>> >> language which is fast -- C++. I suspect that converting not very
>> >> efficient code into yet another language might have dramatic effect
>> >> on performance.
>> That depends. At least Python can clean up its strings, for example.
> I think that symple-minded conversion will turn
> local a = foo bar ;
> a = ["foo", "bar"] ;
> which would not use jam string-caching and might take a lot more
I'm not in the least convinced that jam string-caching is saving
memory overall, since:
a. nothing is ever deallocated
b. All kinds of nasty strings get computed as intermediate values
we'll never care about again, and cached -- mostly due to the
fact that Jam's computational model is so weak.
c. Python "interns" strings too (but more selectively).
> An writing optimizing Jam->Python compiler is scary.
Pshaw. There's not much to optimize. Most of the optimization has
been done by the Python team. They have spent hours making simple
language-level operations fast.
>> > I agree. Scons is a nice build system in many ways being able to use a
>> > 'proper' language to define your builds is good but it suffers from being
>> > pure Python as its dependency checking is just not fast enough for large
>> > projects.
>> I'm not sure that has anything whatsoever to do with Python. Scons'
>> standard dependency checking ignores file dates and examines contents
>> instead. You can turn that off and use a more Jam/Make-like date
>> checking algorithm. Is it still too slow?
> I don't know about that... but I suspect rewrite of "toolset.flags" in C++
> will be twice as fast as in Python.
If that rule is actually sucking down a significant number of cycles
there's something very, very wrong. In v1 it would get called again
for each target, but in v2 it should only be called when the toolset
is initially loaded.
-- Dave Abrahams Boost Consulting http://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