[Pharo-project] ClassTestCase
Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example. What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project. What do you think? Are you agree with that? Cheers, Mariano.
the key point is that we would like to avoid to have red tests all the time so fixing the as yet unclassified should be done before. BTW Does anybody use BadEqualer HashTester PrototypeTester because so far I do not see anybody user of them. They look like experiment code to me. Stef On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It is a must. We have to got all the tests in green. But actually that isn't tested. I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline. Cheers, Mariano. On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
the key point is that we would like to avoid to have red tests all the time so fixing the as yet unclassified should be done before.
BTW Does anybody use BadEqualer HashTester PrototypeTester
because so far I do not see anybody user of them. They look like experiment code to me.
Stef
On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. This way we do not have red tests and still make progress Stef On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
It is a must. We have to got all the tests in green. But actually that isn't tested.
I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline.
Cheers,
Mariano.
On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: the key point is that we would like to avoid to have red tests all the time so fixing the as yet unclassified should be done before.
BTW Does anybody use BadEqualer HashTester PrototypeTester
because so far I do not see anybody user of them. They look like experiment code to me.
Stef
On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
We're working on it, making small changes and creating code standards tests and code quality tests. It would be great to have a way of tracking the results of these tests in a distant future and make them mandatory before integrate new things into the image. Francisco On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. This way we do not have red tests and still make progress Stef
On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
It is a must. We have to got all the tests in green. But actually that isn't tested.
I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline.
Cheers,
Mariano.
On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: the key point is that we would like to avoid to have red tests all the time so fixing the as yet unclassified should be done before.
BTW Does anybody use     BadEqualer     HashTester     PrototypeTester
because so far I do not see anybody user of them. They look like experiment code to me.
Stef
On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
If anyone want, can take a look at: http://www.squeaksource.com/CodeQualityTests http://www.squeaksource.com/CodeStandardsTests And run the tests before committing the next version of their packages. We will try to help to pass the tests as soon as possible. Cheers, Mariano. On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Peñaloza < patchinko@gmail.com> wrote:
We're working on it, making small changes and creating code standards tests and code quality tests.
It would be great to have a way of tracking the results of these tests in a distant future and make them mandatory before integrate new things into the image.
Francisco
On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. This way we do not have red tests and still make progress Stef
On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
It is a must. We have to got all the tests in green. But actually that isn't tested.
I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline.
Cheers,
Mariano.
On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote: the key point is that we would like to avoid to have red tests all the time so fixing the as yet unclassified should be done before.
BTW Does anybody use BadEqualer HashTester PrototypeTester
because so far I do not see anybody user of them. They look like experiment code to me.
Stef
On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Sounds exciting can you tell us a bit more? On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote:
If anyone want, can take a look at:
http://www.squeaksource.com/CodeQualityTests http://www.squeaksource.com/CodeStandardsTests
And run the tests before committing the next version of their packages.
We will try to help to pass the tests as soon as possible.
Cheers,
Mariano.
On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Peñaloza <patchinko@gmail.com> wrote: We're working on it, making small changes and creating code standards tests and code quality tests.
It would be great to have a way of tracking the results of these tests in a distant future and make them mandatory before integrate new things into the image.
Francisco
On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. This way we do not have red tests and still make progress Stef
On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
It is a must. We have to got all the tests in green. But actually that isn't tested.
I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline.
Cheers,
Mariano.
On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: the key point is that we would like to avoid to have red tests all the time so fixing the as yet unclassified should be done before.
BTW Does anybody use BadEqualer HashTester PrototypeTester
because so far I do not see anybody user of them. They look like experiment code to me.
Stef
On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
There are few now, but it was done yesterday in a few hours. We will keep adding new tests to that suites, so suggestions are welcome :). Actually there are only 3 tests there: - One that checks that all the methods in the image are categorized - One that checks that never redefine #doesNotUnderstand: without redefining #respondsTo: and vice versa. - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= nil, etc. as suggested in issue 1594 (Actually, after reading this issue is that we started with this idea). Cheers, Mariano. On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Sounds exciting can you tell us a bit more?
On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote:
If anyone want, can take a look at:
http://www.squeaksource.com/CodeQualityTests http://www.squeaksource.com/CodeStandardsTests
And run the tests before committing the next version of their packages.
We will try to help to pass the tests as soon as possible.
Cheers,
Mariano.
On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Peñaloza < patchinko@gmail.com> wrote: We're working on it, making small changes and creating code standards tests and code quality tests.
It would be great to have a way of tracking the results of these tests in a distant future and make them mandatory before integrate new things into the image.
Francisco
On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. This way we do not have red tests and still make progress Stef
On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
It is a must. We have to got all the tests in green. But actually that isn't tested.
I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline.
Cheers,
Mariano.
On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote: the key point is that we would like to avoid to have red tests all the time so fixing the as yet unclassified should be done before.
BTW Does anybody use BadEqualer HashTester PrototypeTester
because so far I do not see anybody user of them. They look like experiment code to me.
Stef
On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, 23 May 2010, Mariano Abel Coca wrote:
There are few now, but it was done yesterday in a few hours. We will keep adding new tests to that suites, so suggestions are welcome :).
Actually there are only 3 tests there:
- One that checks that all the methods in the image are categorized - One that checks that never redefine #doesNotUnderstand: without redefining #respondsTo: and vice versa. - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= nil, etc. as suggested in issue 1594 (Actually, after reading this issue is that we started with this idea).
"x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and "== nil" is not less readable if you know what #== means (but that's basic smalltalk knowledge, so it's fair to assume that everybody knows it). Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible). So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible. (*) Benchmarks on my slow machine: ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 == nil ] ] timeToRun ]) average asFloat. "===> 386.6" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ] ] timeToRun ]) average asFloat. "===> 586.4" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> 282.3" 586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 393.6" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 585.2" 585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584" Levente
Cheers,
Mariano.
On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Sounds exciting can you tell us a bit more?
On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote:
If anyone want, can take a look at:
http://www.squeaksource.com/CodeQualityTests http://www.squeaksource.com/CodeStandardsTests
And run the tests before committing the next version of their packages.
We will try to help to pass the tests as soon as possible.
Cheers,
Mariano.
On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza < patchinko@gmail.com> wrote: We're working on it, making small changes and creating code standards tests and code quality tests.
It would be great to have a way of tracking the results of these tests in a distant future and make them mandatory before integrate new things into the image.
Francisco
On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. This way we do not have red tests and still make progress Stef
On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
It is a must. We have to got all the tests in green. But actually that isn't tested.
I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline.
Cheers,
Mariano.
On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote: the key point is that we would like to avoid to have red tests all the time so fixing the as yet unclassified should be done before.
BTW Does anybody use BadEqualer HashTester PrototypeTester
because so far I do not see anybody user of them. They look like experiment code to me.
Stef
On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/5/24 Levente Uzonyi <leves@elte.hu>
On Sun, 23 May 2010, Mariano Abel Coca wrote:
There are few now, but it was done yesterday in a few hours. We will keep
adding new tests to that suites, so suggestions are welcome :).
Actually there are only 3 tests there:
- One that checks that all the methods in the image are categorized - One that checks that never redefine #doesNotUnderstand: without redefining #respondsTo: and vice versa. - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= nil, etc. as suggested in issue 1594 (Actually, after reading this issue is that we started with this idea).
"x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and "== nil" is not less readable if you know what #== means (but that's basic smalltalk knowledge, so it's fair to assume that everybody knows it).
Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible).
So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible.
(*) Benchmarks on my slow machine:
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 == nil ] ] timeToRun ]) average asFloat. "===> 386.6"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ] ] timeToRun ]) average asFloat. "===> 586.4"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> 282.3"
586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 393.6"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 585.2"
585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584"
I ask completely in ignorance, but can't we do some Compiler/Parser teaks so that allow us to write the more readable and nice but then it convert them to the fast ones?
Levente
Cheers,
Mariano.
On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse < stephane.ducasse@inria.fr
wrote:
Sounds exciting can you tell us a bit more?
On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote:
If anyone want, can take a look at:
http://www.squeaksource.com/CodeQualityTests http://www.squeaksource.com/CodeStandardsTests
And run the tests before committing the next version of their packages.
We will try to help to pass the tests as soon as possible.
Cheers,
Mariano.
On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza <
patchinko@gmail.com> wrote:
We're working on it, making small changes and creating code standards tests and code quality tests.
It would be great to have a way of tracking the results of these tests in a distant future and make them mandatory before integrate new things into the image.
Francisco
On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What I was thinking mariano is that we could move one class at a time
in classTests and make the tests green.
This way we do not have red tests and still make progress
Stef
On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
It is a must. We have to got all the tests in green. But actually that
isn't tested.
I'll make the tests, I'll fix them, and then I'll send the whole
changes to merge in the baseline.
Cheers,
Mariano.
On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
the key point is that we would like to avoid to have red tests all the
time
so fixing the as yet unclassified should be done before.
BTW Does anybody use BadEqualer HashTester PrototypeTester
because so far I do not see anybody user of them. They look like experiment code to me.
Stef
On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and
remove it. That is because actually it's only being tested for it's
subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code
Standards and Code Quality tests before sending something to merge to
a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 24 May 2010, Mariano Martinez Peck wrote:
2010/5/24 Levente Uzonyi <leves@elte.hu>
On Sun, 23 May 2010, Mariano Abel Coca wrote:
There are few now, but it was done yesterday in a few hours. We will keep
adding new tests to that suites, so suggestions are welcome :).
Actually there are only 3 tests there:
- One that checks that all the methods in the image are categorized - One that checks that never redefine #doesNotUnderstand: without redefining #respondsTo: and vice versa. - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= nil, etc. as suggested in issue 1594 (Actually, after reading this issue is that we started with this idea).
"x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and "== nil" is not less readable if you know what #== means (but that's basic smalltalk knowledge, so it's fair to assume that everybody knows it).
Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible).
So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible.
(*) Benchmarks on my slow machine:
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 == nil ] ] timeToRun ]) average asFloat. "===> 386.6"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ] ] timeToRun ]) average asFloat. "===> 586.4"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> 282.3"
586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 393.6"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 585.2"
585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584"
I ask completely in ignorance, but can't we do some Compiler/Parser teaks so that allow us to write the more readable and nice but then it convert them to the fast ones?
I think "== nil" is just as readable as "isNil" and "isNil ifTrue:" is less readable than "ifNil:". So I don't see what you're suggesting. Levente
Levente
Cheers,
Mariano.
On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse < stephane.ducasse@inria.fr
wrote:
Sounds exciting can you tell us a bit more?
On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote:
If anyone want, can take a look at:
http://www.squeaksource.com/CodeQualityTests http://www.squeaksource.com/CodeStandardsTests
And run the tests before committing the next version of their packages.
We will try to help to pass the tests as soon as possible.
Cheers,
Mariano.
On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza <
patchinko@gmail.com> wrote:
We're working on it, making small changes and creating code standards tests and code quality tests.
It would be great to have a way of tracking the results of these tests in a distant future and make them mandatory before integrate new things into the image.
Francisco
On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What I was thinking mariano is that we could move one class at a time
in classTests and make the tests green.
This way we do not have red tests and still make progress
Stef
On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
It is a must. We have to got all the tests in green. But actually that
isn't tested.
I'll make the tests, I'll fix them, and then I'll send the whole
changes to merge in the baseline.
Cheers,
Mariano.
On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
the key point is that we would like to avoid to have red tests all the
time
so fixing the as yet unclassified should be done before.
BTW Does anybody use BadEqualer HashTester PrototypeTester
because so far I do not see anybody user of them. They look like experiment code to me.
Stef
On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and
remove it. That is because actually it's only being tested for it's
subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code
Standards and Code Quality tests before sending something to merge to
a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano Some of the combinations are inlined automatically by the compiler as levente explained. The problems is that without a rule checking that for me, I cannot remember which one are optimized :) Now the cost is that if you have more inlined expressions, then the decompiler gets more complex. So having a good and flexible decompiler would be a way to favor optimization. For now the list of levente and a slow machine "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." is the one to use Now
2010/5/24 Levente Uzonyi <leves@elte.hu> On Sun, 23 May 2010, Mariano Abel Coca wrote:
There are few now, but it was done yesterday in a few hours. We will keep adding new tests to that suites, so suggestions are welcome :).
Actually there are only 3 tests there:
- One that checks that all the methods in the image are categorized - One that checks that never redefine #doesNotUnderstand: without redefining #respondsTo: and vice versa. - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= nil, etc. as suggested in issue 1594 (Actually, after reading this issue is that we started with this idea).
"x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and "== nil" is not less readable if you know what #== means (but that's basic smalltalk knowledge, so it's fair to assume that everybody knows it).
Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible).
So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible.
(*) Benchmarks on my slow machine:
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 == nil ] ] timeToRun ]) average asFloat. "===> 386.6"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ] ] timeToRun ]) average asFloat. "===> 586.4"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> 282.3"
586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 393.6"
((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 585.2"
585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584"
I ask completely in ignorance, but can't we do some Compiler/Parser teaks so that allow us to write the more readable and nice but then it convert them to the fast ones?
Levente
Cheers,
Mariano.
On Sun, May 23, 2010 at 4:53 AM, Stéphane Ducasse <stephane.ducasse@inria.fr wrote:
Sounds exciting can you tell us a bit more?
On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote:
If anyone want, can take a look at:
http://www.squeaksource.com/CodeQualityTests http://www.squeaksource.com/CodeStandardsTests
And run the tests before committing the next version of their packages.
We will try to help to pass the tests as soon as possible.
Cheers,
Mariano.
On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza < patchinko@gmail.com> wrote: We're working on it, making small changes and creating code standards tests and code quality tests.
It would be great to have a way of tracking the results of these tests in a distant future and make them mandatory before integrate new things into the image.
Francisco
On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. This way we do not have red tests and still make progress Stef
On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
It is a must. We have to got all the tests in green. But actually that isn't tested.
I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline.
Cheers,
Mariano.
On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote: the key point is that we would like to avoid to have red tests all the time so fixing the as yet unclassified should be done before.
BTW Does anybody use BadEqualer HashTester PrototypeTester
because so far I do not see anybody user of them. They look like experiment code to me.
Stef
On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
For now the list of levente and a slow machine
    "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." is the one to use
Please read my comments on the issue tracker. For *any practical* example it doesn't matter what to use speed wise: 1 = nil ifTrue: [ ] 2 == nil ifTrue: [ ] 3 isNil ifTrue: [ ] 4 ifNil: [ ] Personally I find 3 the most readable. 1 and 3 are the only practical ones if you use OODBs, because they are not shortcut by the compiler. I only use 4 for lazy initializers, it makes a good pattern. The use of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable if you don't care about compatibility with other Smalltalk dialects. Lukas -- Lukas Renggli www.lukas-renggli.ch
Lukas what would be good is to have a specific pharo smallLint that we could run to check. My brain is too small for all these details. Stef On May 24, 2010, at 6:18 PM, Lukas Renggli wrote:
For now the list of levente and a slow machine
"So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." is the one to use
Please read my comments on the issue tracker.
For *any practical* example it doesn't matter what to use speed wise:
1 = nil ifTrue: [ ] 2 == nil ifTrue: [ ] 3 isNil ifTrue: [ ] 4 ifNil: [ ]
Personally I find 3 the most readable. 1 and 3 are the only practical ones if you use OODBs, because they are not shortcut by the compiler.
I only use 4 for lazy initializers, it makes a good pattern. The use of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable if you don't care about compatibility with other Smalltalk dialects.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 24 May 2010, Lukas Renggli wrote:
For now the list of levente and a slow machine
    "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." is the one to use
Please read my comments on the issue tracker.
For *any practical* example it doesn't matter what to use speed wise:
That's not true. Most of the time it doesn't matter, but when these checks/conditional statements are in tight loops they can make a huge difference. Core packages have some good code examples and those have to be fast, but not cross-dialect. I'm sure other smalltalks are implemented this way.
1 = nil ifTrue: [ ] 2 == nil ifTrue: [ ] 3 isNil ifTrue: [ ] 4 ifNil: [ ]
IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the moment, so that should be preferred in core packages. 2 is cross-dialect and it's probably the fastest in all dialects, so if I were writing cross-dialect code then I'd probably use that. 3 looks nice and #isNil is inlined in some dialects (AFAIK), but it's "slow" in Squeak/Pharo. 1 just looks bad, I can't imagine an OODB that doesn't map it's "null object" directly to nil, otherwise #= will be asymmetric: null = nil -> true nil = null -> false Btw I hope we will have an inlining JIT soon which can decrease/eliminate these performance differences. Levente
Personally I find 3 the most readable. 1 and 3 are the only practical ones if you use OODBs, because they are not shortcut by the compiler.
I only use 4 for lazy initializers, it makes a good pattern. The use of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable if you don't care about compatibility with other Smalltalk dialects.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the moment, so that should be preferred in core packages.
It should not be preferred or changes unless you can prove a real performance benefit. I still haven't seen a single realistic benchmark with real code (from Pharo, Seaside, Pier, ...) where you can measure a real difference between these 4 variants.
1 just looks bad, I can't imagine an OODB that doesn't map it's "null object" directly to nil, otherwise #= will be asymmetric: null = nil -> true nil = null -> false
That's not the problem. The problem is when you have proxy objects then all these inlined an shortcut variants fail miserably. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Mon, 24 May 2010, Lukas Renggli wrote:
IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the moment, so that should be preferred in core packages.
It should not be preferred or changes unless you can prove a real performance benefit. I still haven't seen a single realistic benchmark with real code (from Pharo, Seaside, Pier, ...) where you can measure a real difference between these 4 variants.
Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and run them in both images. For now I can only show a microbenchmark that I evaluated in PharoCore-1.1-11367 on my slow machine: Original: (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next isNil ] whileFalse ] timeToRun ] ] #(9928 9733 9753 9703 9711) Then I replaced the #isNil send to == nil: (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next == nil ] whileFalse ] timeToRun ] ] #(9214 9301 9419 9273 9285) Not bad 4.8% faster. Then I replaced the line character1 isNil ifTrue: [^ nil]. with character1 ifNil: [^ nil]. in UTF8TextConverter >> #nextFromStream:. (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next == nil ] whileFalse ] timeToRun ] ] #(8947 8779 8814 8845 8810). 5% faster than the previous. Removing 2 #isNil sends from the tight loop gave ~10% speedup. Levente
1 just looks bad, I can't imagine an OODB that doesn't map it's "null object" directly to nil, otherwise #= will be asymmetric: null = nil -> true nil = null -> false
That's not the problem. The problem is when you have proxy objects then all these inlined an shortcut variants fail miserably.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
5 % is cool in such scenario. Thanks levente. I believe in small speed ups and you show that. Stef On May 24, 2010, at 10:47 PM, Levente Uzonyi wrote:
On Mon, 24 May 2010, Lukas Renggli wrote:
IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the moment, so that should be preferred in core packages.
It should not be preferred or changes unless you can prove a real performance benefit. I still haven't seen a single realistic benchmark with real code (from Pharo, Seaside, Pier, ...) where you can measure a real difference between these 4 variants.
Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and run them in both images.
For now I can only show a microbenchmark that I evaluated in PharoCore-1.1-11367 on my slow machine:
Original: (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next isNil ] whileFalse ] timeToRun ] ] #(9928 9733 9753 9703 9711)
Then I replaced the #isNil send to == nil:
(1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next == nil ] whileFalse ] timeToRun ] ] #(9214 9301 9419 9273 9285)
Not bad 4.8% faster. Then I replaced the line character1 isNil ifTrue: [^ nil]. with character1 ifNil: [^ nil]. in UTF8TextConverter >> #nextFromStream:.
(1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next == nil ] whileFalse ] timeToRun ] ] #(8947 8779 8814 8845 8810). 5% faster than the previous.
Removing 2 #isNil sends from the tight loop gave ~10% speedup.
Levente
1 just looks bad, I can't imagine an OODB that doesn't map it's "null object" directly to nil, otherwise #= will be asymmetric: null = nil -> true nil = null -> false
That's not the problem. The problem is when you have proxy objects then all these inlined an shortcut variants fail miserably.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 2010-05-24, at 1:47 PM, Levente Uzonyi wrote:
On Mon, 24 May 2010, Lukas Renggli wrote:
IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the moment, so that should be preferred in core packages.
It should not be preferred or changes unless you can prove a real performance benefit. I still haven't seen a single realistic benchmark with real code (from Pharo, Seaside, Pier, ...) where you can measure a real difference between these 4 variants.
Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and run them in both images.
Well what is going on is that you are changing the foo isNil ifTrue: which is a message send for the isNil into a foo == nil ifTrue: which then does an object identity check in byte codes. Because messages sends are *slow* removing one from millions of executions does improve things. However what be more clever is changing the compiler to optimize the use of isNil so you maintain readability without a performance penalty. Also consider 'first' 'second' Well and the case of the simple accessor self foo ifTrue:[] where foo ^foo -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Mon, 24 May 2010, John M McIntosh wrote:
On 2010-05-24, at 1:47 PM, Levente Uzonyi wrote:
On Mon, 24 May 2010, Lukas Renggli wrote:
IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the moment, so that should be preferred in core packages.
It should not be preferred or changes unless you can prove a real performance benefit. I still haven't seen a single realistic benchmark with real code (from Pharo, Seaside, Pier, ...) where you can measure a real difference between these 4 variants.
Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and run them in both images.
Well what is going on is that you are changing the foo isNil ifTrue: which is a message send for the isNil into a foo == nil ifTrue: which then does an object identity check in byte codes.
Because messages sends are *slow* removing one from millions of executions does improve things.
However what be more clever is changing the compiler to optimize the use of isNil so you maintain readability without a performance penalty.
Is "isNil" really more readable than "== nil"?
Also consider 'first' 'second'
Well and the case of the simple accessor
self foo ifTrue:[] where foo ^foo
Inlining more methods is a bad idea IMHO. It makes the compiler and the decompiler more complex. An inlining JIT is the real solution. Levente
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Is "isNil" really more readable than "== nil"? imho yes... i find it more readable, more "smalltalkish" but the conversation ended up being about performance rather than if it's more readable or not so obviously there is a bigger issue :) Francisco On Mon, May 24, 2010 at 11:22 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Mon, 24 May 2010, John M McIntosh wrote:
On 2010-05-24, at 1:47 PM, Levente Uzonyi wrote:
On Mon, 24 May 2010, Lukas Renggli wrote:
IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at the moment, so that should be preferred in core packages.
It should not be preferred or changes unless you can prove a real performance benefit. I still haven't seen a single realistic benchmark with real code (from Pharo, Seaside, Pier, ...) where you can measure a real difference between these 4 variants.
Well, just replace all uses of == nil and #ifNil:, etc with isNil and isNil ifTrue: etc. Then get some benchmarks which you accept as realistic and run them in both images.
Well what is going on is that you are changing the foo isNil ifTrue: which is a message send for the isNil into a foo == nil ifTrue: which then does an object identity check in byte codes.
Because messages sends are *slow* removing one from millions of executions does improve things.
However what be more clever is changing the compiler to optimize the use of isNil so you maintain readability without a performance penalty.
Is "isNil" really more readable than "== nil"?
Also consider 'first' 'second'
Well and the case of the simple accessor
self foo ifTrue:[] where foo ^foo
Inlining more methods is a bad idea IMHO. It makes the compiler and the decompiler more complex. An inlining JIT is the real solution.
Levente
--
=========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Â Twitter: Â squeaker68882 Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com
===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 2010-05-24, at 7:22 PM, Levente Uzonyi wrote:
Inlining more methods is a bad idea IMHO. It makes the compiler and the decompiler more complex. An inlining JIT is the real solution.
Levente
If it's smalltalk code underfoot then likely a bunch of people might have an interest or at least be able to hack, criticize, be happy, or ignore it. If it's a JIT buried in SLANG, C or assembler then I'd guess not more than 5 people would know anything about how it works, or figure out how to fix it. -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
We're working on it, making small changes and creating code standards tests and code quality tests.
It would be great to have a way of tracking the results of these tests in a distant future and make them mandatory before integrate new things into the image.
Francisco Three points: - I agree on the principle. Normally I read all the code that is integrated - now we should pay attention. I prefer to put code that make progress but is not perfect versus doing nothing and waiting for a better one - then people can comment on the submission made on the tracker but really few do it. So what is the solution let the code rot there? And kill our good energy. So you see nothing is simple. This is clear that having a nice bunch of SmallLint rules should not hurt :) Stef
Francisco
On Sat, May 22, 2010 at 7:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. This way we do not have red tests and still make progress Stef
On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote:
It is a must. We have to got all the tests in green. But actually that isn't tested.
I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline.
Cheers,
Mariano.
On Sat, May 22, 2010 at 2:58 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: the key point is that we would like to avoid to have red tests all the time so fixing the as yet unclassified should be done before.
BTW Does anybody use BadEqualer HashTester PrototypeTester
because so far I do not see anybody user of them. They look like experiment code to me.
Stef
On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote:
Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example.
What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project.
What do you think? Are you agree with that?
Cheers,
Mariano. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Francisco Ortiz Peñaloza -
John M McIntosh -
Levente Uzonyi -
Lukas Renggli -
Mariano Abel Coca -
Mariano Martinez Peck -
Stéphane Ducasse