Hi!
I have been working on a new profiler to reduce the amount of candidates when analyzing a Smalltalk project. The idea is to run the test to know exactly what are the methods that are invoked. I would like you to try my implementation. With Mondrian, the standard candidates operator produces 27,890 candidates for all the methods. Using the profiler, it is reduced to 9,828. The amount of candidates is significantly reduced. Below two screenshots of a complexity blueprint. I made it on Arki. One with the normal candidates, and one with the profiling. Go to the the squeaksource project ArchitectureMonitor. There is a configuration in it. Load the last version. Then you should have the option: I quickly worked on this, so it may be that it contains some error. I would like to know whether you like this approach or not. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev ArkiWithoutProfile.png (27K) Download Attachment ArkiWithProfile.png (19K) Download Attachment Screen shot 2011-05-06 at 11.44.41.png (41K) Download Attachment |
alex
do you mean that you execute the system and keep trace. or this is just static analysis. Stef On May 6, 2011, at 5:48 PM, Alexandre Bergel wrote: > Hi! > > I have been working on a new profiler to reduce the amount of candidates when analyzing a Smalltalk project. The idea is to run the test to know exactly what are the methods that are invoked. > > I would like you to try my implementation. > With Mondrian, the standard candidates operator produces 27,890 candidates for all the methods. Using the profiler, it is reduced to 9,828. The amount of candidates is significantly reduced. > > Below two screenshots of a complexity blueprint. I made it on Arki. One with the normal candidates, and one with the profiling. > > <ArkiWithoutProfile.png><ArkiWithProfile.png> > > > Go to the the squeaksource project ArchitectureMonitor. There is a configuration in it. Load the last version. Then you should have the option: > > <Screen shot 2011-05-06 at 11.44.41.png> > > I quickly worked on this, so it may be that it contains some error. I would like to know whether you like this approach or not. > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
He is executing the tests to get the type at runtime.
Alex, I think it's nice to have this possibility. The problem with this approach is that you can only get the relationships that are present in the tests. This can be Ok, or not, depending on the use case. Cheers, Doru On 7 May 2011, at 10:37, Stéphane Ducasse wrote: > alex > > do you mean that you execute the system and keep trace. or this is just static analysis. > > Stef > > > On May 6, 2011, at 5:48 PM, Alexandre Bergel wrote: > >> Hi! >> >> I have been working on a new profiler to reduce the amount of candidates when analyzing a Smalltalk project. The idea is to run the test to know exactly what are the methods that are invoked. >> >> I would like you to try my implementation. >> With Mondrian, the standard candidates operator produces 27,890 candidates for all the methods. Using the profiler, it is reduced to 9,828. The amount of candidates is significantly reduced. >> >> Below two screenshots of a complexity blueprint. I made it on Arki. One with the normal candidates, and one with the profiling. >> >> <ArkiWithoutProfile.png><ArkiWithProfile.png> >> >> >> Go to the the squeaksource project ArchitectureMonitor. There is a configuration in it. Load the last version. Then you should have the option: >> >> <Screen shot 2011-05-06 at 11.44.41.png> >> >> I quickly worked on this, so it may be that it contains some error. I would like to know whether you like this approach or not. >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "What is more important: To be happy, or to make happy?" _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Stéphane Ducasse
> do you mean that you execute the system and keep trace. or this is just static analysis.
Essentially, each method knows what are the methods it calls. I found this pretty cool actually. Cheers, Alexandre > > > On May 6, 2011, at 5:48 PM, Alexandre Bergel wrote: > >> Hi! >> >> I have been working on a new profiler to reduce the amount of candidates when analyzing a Smalltalk project. The idea is to run the test to know exactly what are the methods that are invoked. >> >> I would like you to try my implementation. >> With Mondrian, the standard candidates operator produces 27,890 candidates for all the methods. Using the profiler, it is reduced to 9,828. The amount of candidates is significantly reduced. >> >> Below two screenshots of a complexity blueprint. I made it on Arki. One with the normal candidates, and one with the profiling. >> >> <ArkiWithoutProfile.png><ArkiWithProfile.png> >> >> >> Go to the the squeaksource project ArchitectureMonitor. There is a configuration in it. Load the last version. Then you should have the option: >> >> <Screen shot 2011-05-06 at 11.44.41.png> >> >> I quickly worked on this, so it may be that it contains some error. I would like to know whether you like this approach or not. >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Tudor Girba
> He is executing the tests to get the type at runtime.
> > Alex, I think it's nice to have this possibility. The problem with this approach is that you can only get the relationships that are present in the tests. This can be Ok, or not, depending on the use case. Indeed, but it works relatively well in my setting. I would like to keep track of dependencies of various software programs in which I am involved in their development. I also made a small Glamour browser that shows me the case that remains unresolved. In that case, I can write new test or give an arbitrary unique candidate. So far, I am satisfied with this solution. But again, this works if you have unit tests. Cheers, Alexandre > > > On 7 May 2011, at 10:37, Stéphane Ducasse wrote: > >> alex >> >> do you mean that you execute the system and keep trace. or this is just static analysis. >> >> Stef >> >> >> On May 6, 2011, at 5:48 PM, Alexandre Bergel wrote: >> >>> Hi! >>> >>> I have been working on a new profiler to reduce the amount of candidates when analyzing a Smalltalk project. The idea is to run the test to know exactly what are the methods that are invoked. >>> >>> I would like you to try my implementation. >>> With Mondrian, the standard candidates operator produces 27,890 candidates for all the methods. Using the profiler, it is reduced to 9,828. The amount of candidates is significantly reduced. >>> >>> Below two screenshots of a complexity blueprint. I made it on Arki. One with the normal candidates, and one with the profiling. >>> >>> <ArkiWithoutProfile.png><ArkiWithProfile.png> >>> >>> >>> Go to the the squeaksource project ArchitectureMonitor. There is a configuration in it. Load the last version. Then you should have the option: >>> >>> <Screen shot 2011-05-06 at 11.44.41.png> >>> >>> I quickly worked on this, so it may be that it contains some error. I would like to know whether you like this approach or not. >>> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
On 7 May 2011, at 15:46, Alexandre Bergel wrote: >> He is executing the tests to get the type at runtime. >> >> Alex, I think it's nice to have this possibility. The problem with this approach is that you can only get the relationships that are present in the tests. This can be Ok, or not, depending on the use case. > > Indeed, but it works relatively well in my setting. I would like to keep track of dependencies of various software programs in which I am involved in their development. > I also made a small Glamour browser that shows me the case that remains unresolved. In that case, I can write new test or give an arbitrary unique candidate. Yes, I like the idea of going back to the tests. Basically, this shows the test coverage of state, rather than the one of functionality :). Cheers, Doru > So far, I am satisfied with this solution. But again, this works if you have unit tests. > > Cheers, > Alexandre > >> >> >> On 7 May 2011, at 10:37, Stéphane Ducasse wrote: >> >>> alex >>> >>> do you mean that you execute the system and keep trace. or this is just static analysis. >>> >>> Stef >>> >>> >>> On May 6, 2011, at 5:48 PM, Alexandre Bergel wrote: >>> >>>> Hi! >>>> >>>> I have been working on a new profiler to reduce the amount of candidates when analyzing a Smalltalk project. The idea is to run the test to know exactly what are the methods that are invoked. >>>> >>>> I would like you to try my implementation. >>>> With Mondrian, the standard candidates operator produces 27,890 candidates for all the methods. Using the profiler, it is reduced to 9,828. The amount of candidates is significantly reduced. >>>> >>>> Below two screenshots of a complexity blueprint. I made it on Arki. One with the normal candidates, and one with the profiling. >>>> >>>> <ArkiWithoutProfile.png><ArkiWithProfile.png> >>>> >>>> >>>> Go to the the squeaksource project ArchitectureMonitor. There is a configuration in it. Load the last version. Then you should have the option: >>>> >>>> <Screen shot 2011-05-06 at 11.44.41.png> >>>> >>>> I quickly worked on this, so it may be that it contains some error. I would like to know whether you like this approach or not. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "What is more important: To be happy, or to make happy?" >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |