www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Please send me your longest DustMite runs!

reply 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.
Apr 23
next sibling parent 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 :/
Apr 23
prev sibling next sibling parent reply 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.
Apr 23
next sibling parent 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
Apr 24
prev sibling parent 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)
Apr 24
prev sibling next sibling parent 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
Apr 24
prev sibling parent 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.
Apr 24