http://d.puremagic.com/issues/show_bug.cgi?id=7442
--- Comment #10 from Don <[email protected]> 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 > RAM > 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
