On 05/01/2013 1:37 PM, Patrick Walton wrote:
First off, I do not see any way we can improve *general* compiler
performance by an order of magnitude.
I don't feel this sort of quantitative statement can be made, from where
we are now. When I say I expect we should be able to get it an order of
On 06/01/2013 2:57 PM, Tim Chevalier wrote:
Personally, I think our time would be better spent making it easy to break
large projects up into multiple finer-grained crates. We should be able to
tell cargo and/or the work-in-progress `fbuild` workalike to compile a crate
and rebuild all of its
Could you use multiple threads to type check and code gen in parallel?
Could you retain information from a previous run of the compiler and
reuse it (especially for code generation)?
___
Rust-dev mailing list
Rust-dev@mozilla.org
What stands in the way of doing incremental compilation?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 1/6/13 9:50 AM, Lindsey Kuper wrote:
What stands in the way of doing incremental compilation?
Personally, I think our time would be better spent making it easy to
break large projects up into multiple finer-grained crates. We should be
able to tell cargo and/or the work-in-progress
Niko Matsakis wrote:
Here are some relatively simple things we could do to improve
performance in type-checking, off the top of my head:
I should add that the overall impact of these (and other) changes might
easily be small. I know you have profiles showing malloc to be a
relatively
On Sun, Jan 6, 2013 at 10:29 AM, Patrick Walton pwal...@mozilla.com wrote:
On 1/6/13 9:50 AM, Lindsey Kuper wrote:
What stands in the way of doing incremental compilation?
Personally, I think our time would be better spent making it easy to break
large projects up into multiple
I thought I'd begin a discussion as to how to improve performance of the
rustc compiler.
First off, I do not see any way we can improve *general* compiler
performance by an order of magnitude. The language is simply designed to
favor safety and expressivity over compile-time performance.
I realized I forgot some things.
# Garbage collection
* Not generating reference count manipulations (which would be possible
if we switched to tracing GC) improves code generation speed. I created
a test that resulted in a 22.5% improvement in LLVM pass speed. Not an
order of magnitude
