On 2013.06.16 03:18:18 +0200, Björn Steinbrink wrote:
On 2013.06.15 20:46:44 +0200, Björn Steinbrink wrote:
On 2013.06.15 11:34:16 -0700, Graydon Hoare wrote:
On 15/06/2013 10:09 AM, Björn Steinbrink wrote:
This seems to be due to the landing pads for the function calls. Each
I saw some more speculation on how to make rustc not-so-terriby-slow to
compile today, including dramatic structural changes like splitting it
into sub-crates. Please don't do this; it's papering over much more
readily solvable problems. A 80kloc library does not need to be
generating 16mb of
From a holistic approach, does this problem point to :
1. More LLVM tweaking in general is needed ?
2. More use of libraries and better libraries are needed ?
3. Both 1 and 2 ?
On Sat, Jun 15, 2013 at 3:26 AM, Graydon Hoare gray...@mozilla.com wrote:
I saw some more speculation on how to
On Sat, Jun 15, 2013 at 8:55 AM, Thad Guidry thadgui...@gmail.com wrote:
From a holistic approach, does this problem point to :
Mostly it points to the code being old and crappy. LLVM IR generation
needs to be improved a ton, yes. Libraries? Not sure.
On 6/15/13 1:26 AM, Graydon Hoare wrote:
I saw some more speculation on how to make rustc not-so-terriby-slow to
compile today, including dramatic structural changes like splitting it
into sub-crates. Please don't do this; it's papering over much more
readily solvable problems. A 80kloc library
On 2013.06.15 01:26:48 -0700, Graydon Hoare wrote:
Here are two simple listings of symbols we're generating:
http://people.mozilla.org/~graydon/symbols-by-size.txt
http://people.mozilla.org/~graydon/symbols-by-name.txt
Some things should be immediately apparent:
- We're generating
On 15/06/2013 10:09 AM, Björn Steinbrink wrote:
This seems to be due to the landing pads for the function calls. Each
contains one more call to drop, so the code grows quadratically with the
number of allocations.
Yes. Last time I was in the landing pad code (on the return-unwind
branch) I
On 6/15/13 10:09 AM, Björn Steinbrink wrote:
This seems to be due to the landing pads for the function calls. Each
contains one more call to drop, so the code grows quadratically with the
number of allocations.
I had a patch that's bitrotted to turn off table-driven unwinding on
failure
On 2013.06.15 11:34:16 -0700, Graydon Hoare wrote:
On 15/06/2013 10:09 AM, Björn Steinbrink wrote:
This seems to be due to the landing pads for the function calls. Each
contains one more call to drop, so the code grows quadratically with the
number of allocations.
Yes. Last time I was in
On 15/06/2013 9:49 AM, Patrick Walton wrote:
On 6/15/13 1:26 AM, Graydon Hoare wrote:
I saw some more speculation on how to make rustc not-so-terriby-slow to
compile today, including dramatic structural changes like splitting it
into sub-crates. Please don't do this; it's papering over much
On 6/15/13 11:59 AM, Graydon Hoare wrote:
Because it was being proposed as a solution to speed, but:
Well, in my case, I often start swapping, which kills codegen
performance. So it would help my particular use case. (It would also
help us land the GC.)
Patrick
On 15/06/2013 12:25 PM, Patrick Walton wrote:
On 6/15/13 11:59 AM, Graydon Hoare wrote:
Because it was being proposed as a solution to speed, but:
Well, in my case, I often start swapping, which kills codegen
performance. So it would help my particular use case. (It would also
help us land
On 2013.06.15 12:25:49 -0700, Patrick Walton wrote:
On 6/15/13 11:59 AM, Graydon Hoare wrote:
Because it was being proposed as a solution to speed, but:
Well, in my case, I often start swapping, which kills codegen
performance. So it would help my particular use case. (It would also
help us
On 15/06/2013 12:44 PM, Björn Steinbrink wrote:
On 2013.06.15 12:25:49 -0700, Patrick Walton wrote:
On 6/15/13 11:59 AM, Graydon Hoare wrote:
Because it was being proposed as a solution to speed, but:
Well, in my case, I often start swapping, which kills codegen
performance. So it would help
On 2013.06.15 20:46:44 +0200, Björn Steinbrink wrote:
On 2013.06.15 11:34:16 -0700, Graydon Hoare wrote:
On 15/06/2013 10:09 AM, Björn Steinbrink wrote:
This seems to be due to the landing pads for the function calls. Each
contains one more call to drop, so the code grows quadratically
On 6/15/13 6:18 PM, Björn Steinbrink wrote:
OK, so I have a hackish version [1] that mostly handles growing
landing pads within a single scope (in nested scopes, the parent cleanup
blocks are already reused). Mostly because there seems to be some
problem with e.g. ~int. Consecutive let x = ~5
16 matches
Mail list logo
