• Vladimir Panteleev (9/9) Apr 23 2021 - Was there a bug / program / codebase that took an exceptionally
• deadalnix (5/14) Apr 23 2021 Crap, I had run that literally took several days to run, but the
• Berni44 (8/10) Apr 23 2021 Reducing whole Phobos takes long. I did that several times a year
• Johan Engelen (7/17) Apr 24 2021 I cannot share the code. Dustmiting at Weka always takes a very
• MoonlightSentinel (5/9) Apr 24 2021 Some things that speed up reductions for Phobos:
• Andre Pany (12/21) Apr 24 2021 I think Steven was facing the issue that testing for compiler /
• MoonlightSentinel (7/8) Apr 24 2021 Could Dustmite try to inline functions?

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

- Was there a bug / program / codebase that took an exceptionally 
long time to reduce with DustMite?
- Do you still have a copy of that (un-reduced) code and test 
script?
- Is it something you can share?

If yes, then please post it! (Or send me the code)

I have some ideas for improving DustMite's reduction strategies, 
but being able to measure any potential improvements on 
real-world cases would be massively helpful.

deadalnix <deadalnix gmail.com> writes:

On Friday, 23 April 2021 at 23:17:41 UTC, Vladimir Panteleev 
wrote:
 - Was there a bug / program / codebase that took an 
 exceptionally long time to reduce with DustMite?
 - Do you still have a copy of that (un-reduced) code and test 
 script?
 - Is it something you can share?

 If yes, then please post it! (Or send me the code)

 I have some ideas for improving DustMite's reduction 
 strategies, but being able to measure any potential 
 improvements on real-world cases would be massively helpful.

Crap, I had run that literally took several days to run, but the 
related bug have been fixes and I haven't kept the specifics of 
how to repro :/

Berni44 <someone somemail.com> writes:

On Friday, 23 April 2021 at 23:17:41 UTC, Vladimir Panteleev 
wrote:
 - Was there a bug / program / codebase that took an 
 exceptionally long time to reduce with DustMite?

Reducing whole Phobos takes long. I did that several times a year 
ago. Took several days. I think, the problem is, that it takes 
long until the connections between the modules (imports) are cut. 
After these are gone, whole files can be removed. But at that 
stage dustmite already tries to remove single lines or parts of 
them.

Johan Engelen <j j.nl> writes:

On Saturday, 24 April 2021 at 06:49:51 UTC, Berni44 wrote:
 On Friday, 23 April 2021 at 23:17:41 UTC, Vladimir Panteleev 
 wrote:
 - Was there a bug / program / codebase that took an 
 exceptionally long time to reduce with DustMite?

 Reducing whole Phobos takes long. I did that several times a 
 year ago. Took several days. I think, the problem is, that it 
 takes long until the connections between the modules (imports) 
 are cut. After these are gone, whole files can be removed. But 
 at that stage dustmite already tries to remove single lines or 
 parts of them.

I cannot share the code. Dustmiting at Weka always takes a very 
long time, the reason I suspect is all the module connections 
indeed. When starting a dustmite session I now often start with 
emptying the bodies of functions (easy for void-returning 
functions), to cut the module dependencies.

-Johan

MoonlightSentinel <moonlightsentinel disroot.org> writes:

On Saturday, 24 April 2021 at 06:49:51 UTC, Berni44 wrote:
 Reducing whole Phobos takes long. I did that several times a 
 year ago. Took several days. I think, the problem is, that it 
 takes long until the connections between the modules (imports) 
 are cut. [...]

Some things that speed up reductions for Phobos:

- delete std/package.d
- use specific imports (e.g. import std.algorithm.sorting instead 
of std.algorithm)

Andre Pany <andre s-e-a-p.de> writes:

On Friday, 23 April 2021 at 23:17:41 UTC, Vladimir Panteleev 
wrote:
 - Was there a bug / program / codebase that took an 
 exceptionally long time to reduce with DustMite?
 - Do you still have a copy of that (un-reduced) code and test 
 script?
 - Is it something you can share?

 If yes, then please post it! (Or send me the code)

 I have some ideas for improving DustMite's reduction 
 strategies, but being able to measure any potential 
 improvements on real-world cases would be massively helpful.

I think Steven was facing the issue that testing for compiler / 
linker return code is not useful. Dustmite was running a long 
time and linker status code was at the end caused not by the 
intended error but by just removing all coding lines.
In most cases you really have to test the text output of 
compiler/linker.

You may just add a warning line while using return code to make 
new users aware of this behavior.

Kind regards
Andre

MoonlightSentinel <moonlightsentinel disroot.org> writes:

On Friday, 23 April 2021 at 23:17:41 UTC, Vladimir Panteleev 
wrote:
 I have some ideas for improving DustMite's reduction [...]

Could Dustmite try to inline functions?

My reductions tend to end with several/a lot of small functions 
s.t. I have to inline them by hand. It might also help to narrow 
down the current code base in cases where inlining removes the 
need for several imports.