--- Comment #10 from Don <> 2012-04-29 00:02:21 PDT ---
(In reply to comment #7)
> I investigated this further and conclude that there are 2 factors at work.
> I removed few thousands of codepoints from Letter, so it doesn't run out of 
> outright.(see code below)
> Also separated parse from build steps.
> Here are collected stats on CTFE.
> parse only:
>         ---- CTFE Performance ----
> max call depth = 20     max stack = 44
> array allocs = 2761     assignments = 430837
> build:
>         ---- CTFE Performance ----
> max call depth = 20     max stack = 73
> array allocs = 8264     assignments = 1293421
> Parsing creates all the datastructures for unicode table machinery
> it takes slightly less then half of all allocs already.
> Another thing to notice is it fetures higher allocations per assigment.
> Then comes the codegen step and it's CTFE only and far more alloc happy. 
> Frankly I see no way to reduce all of this alloc fun because of COW
> that will ruin any attempt to preallocate buffer for generated code. 
> Am I right that arrays do dup on every write?

No, that was true a year or so ago, but not any more. One case which still
causing array dups is comparing slices of arrays (eg, if (x[0..5] == y). I've
put the machinery in place to get rid of that now (it's not gone yet, I need
another simple pull request for that). That _might_ help a little bit.

Slicing also causes array dups with ~, eg z = x[0..5] ~ y; creates a temporary
array with x[0..5]. But those are the only two that I know of.

Clearly in this case, it's slow because it does 1.3 million assignments. It's a
duplicate of bug 6498, unless you can find some way of drastically reducing the
work it has to do.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to