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 <le...@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.duca...@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 < > patchi...@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.duca...@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.duca...@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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project