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
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 Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch 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."
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Stéphane Ducasse -
Tudor Girba