I wouldn't be surprised if there wasn't more low-hanging fruit like this.
DateAndTime class>>#now is purposefully "slow" to assure DateAndTime now < DateAndTime now. Dave, I'm not sure whether you preserved that behavior, if not it might not be a very fair benchmark comparison..
On Mon, Jun 2, 2014 at 9:53 AM, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-cmm.855.mcz
==================== Summary ====================
Name: Kernel-cmm.855 Author: cmm Time: 2 June 2014, 9:53:24.175 am UUID: 478f3548-e587-4dd9-8962-d6ba6dbe2035 Ancestors: Kernel-eem.854
- A simple fix for an 8X performance improvement in DateAndTime>>#< as reported by LXTestDateAndTimePerformance.
=============== Diff against Kernel-eem.854 ===============
Item was changed: ----- Method: DateAndTime>>< (in category 'ansi protocol') -----
- < comparand
- < comparand "comparand conforms to protocol DateAndTime, or can be converted into something that conforms."
| lvalue rvalue comparandAsDateAndTime |
| lticks rticks comparandAsDateAndTime | comparandAsDateAndTime := comparand asDateAndTime. offset = comparandAsDateAndTime offset
ifTrue:
[ lvalue := self.
rvalue := comparandAsDateAndTime ]
ifFalse:
[ lvalue := self asUTC.
rvalue := comparandAsDateAndTime asUTC ].
^ lvalue julianDayNumber < rvalue julianDayNumber or:
[ lvalue julianDayNumber > rvalue julianDayNumber
ifTrue: [ false ]
ifFalse:
[ lvalue secondsSinceMidnight < rvalue secondsSinceMidnight or:
[ lvalue secondsSinceMidnight > rvalue secondsSinceMidnight
ifTrue: [ false ]
ifFalse: [ lvalue nanoSecond < rvalue nanoSecond ] ] ] ]!
ifTrue: [lticks := self ticks.
rticks := comparandAsDateAndTime ticks]
ifFalse: [lticks := self asUTC ticks.
rticks := comparandAsDateAndTime asUTC ticks].
^ lticks first < rticks first
or: [lticks first > rticks first
ifTrue: [false]
ifFalse: [lticks second < rticks second
or: [lticks second > rticks second
ifTrue: [false]
ifFalse: [lticks third < rticks third]]]]
- !
Item was changed: ----- Method: DateAndTime>>= (in category 'ansi protocol') ----- = aDateAndTimeOrTimeStamp self == aDateAndTimeOrTimeStamp ifTrue: [ ^ true ]. ((aDateAndTimeOrTimeStamp isKindOf: self class) or: [aDateAndTimeOrTimeStamp isKindOf: DateAndTime orOf: TimeStamp]) ifFalse: [ ^ false ]. ^ self offset = aDateAndTimeOrTimeStamp offset ifTrue: [ self hasEqualTicks: aDateAndTimeOrTimeStamp ]
ifFalse: [ self asUTC hasEqualTicks: aDateAndTimeOrTimeStamp asUTC ]!
ifFalse: [ self asUTC ticks = aDateAndTimeOrTimeStamp asUTC ticks ]!
On Mon, Jun 02, 2014 at 10:14:15AM -0500, Chris Muller wrote:
I wouldn't be surprised if there wasn't more low-hanging fruit like this.
Well done!
DateAndTime class>>#now is purposefully "slow" to assure DateAndTime now < DateAndTime now. Dave, I'm not sure whether you preserved that behavior, if not it might not be a very fair benchmark comparison..
No, I did not preserve that behavior.
Dave
On Mon, Jun 2, 2014 at 9:53 AM, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-cmm.855.mcz
==================== Summary ====================
Name: Kernel-cmm.855 Author: cmm Time: 2 June 2014, 9:53:24.175 am UUID: 478f3548-e587-4dd9-8962-d6ba6dbe2035 Ancestors: Kernel-eem.854
- A simple fix for an 8X performance improvement in DateAndTime>>#< as reported by LXTestDateAndTimePerformance.
=============== Diff against Kernel-eem.854 ===============
Item was changed: ----- Method: DateAndTime>>< (in category 'ansi protocol') -----
- < comparand
- < comparand "comparand conforms to protocol DateAndTime, or can be converted into something that conforms."
| lvalue rvalue comparandAsDateAndTime |
| lticks rticks comparandAsDateAndTime | comparandAsDateAndTime := comparand asDateAndTime. offset = comparandAsDateAndTime offset
ifTrue:
[ lvalue := self.
rvalue := comparandAsDateAndTime ]
ifFalse:
[ lvalue := self asUTC.
rvalue := comparandAsDateAndTime asUTC ].
^ lvalue julianDayNumber < rvalue julianDayNumber or:
[ lvalue julianDayNumber > rvalue julianDayNumber
ifTrue: [ false ]
ifFalse:
[ lvalue secondsSinceMidnight < rvalue secondsSinceMidnight or:
[ lvalue secondsSinceMidnight > rvalue secondsSinceMidnight
ifTrue: [ false ]
ifFalse: [ lvalue nanoSecond < rvalue nanoSecond ] ] ] ]!
ifTrue: [lticks := self ticks.
rticks := comparandAsDateAndTime ticks]
ifFalse: [lticks := self asUTC ticks.
rticks := comparandAsDateAndTime asUTC ticks].
^ lticks first < rticks first
or: [lticks first > rticks first
ifTrue: [false]
ifFalse: [lticks second < rticks second
or: [lticks second > rticks second
ifTrue: [false]
ifFalse: [lticks third < rticks third]]]]
- !
Item was changed: ----- Method: DateAndTime>>= (in category 'ansi protocol') ----- = aDateAndTimeOrTimeStamp self == aDateAndTimeOrTimeStamp ifTrue: [ ^ true ]. ((aDateAndTimeOrTimeStamp isKindOf: self class) or: [aDateAndTimeOrTimeStamp isKindOf: DateAndTime orOf: TimeStamp]) ifFalse: [ ^ false ]. ^ self offset = aDateAndTimeOrTimeStamp offset ifTrue: [ self hasEqualTicks: aDateAndTimeOrTimeStamp ]
ifFalse: [ self asUTC hasEqualTicks: aDateAndTimeOrTimeStamp asUTC ]!
ifFalse: [ self asUTC ticks = aDateAndTimeOrTimeStamp asUTC ticks ]!
On Mon, Jun 2, 2014 at 6:24 PM, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Jun 02, 2014 at 10:14:15AM -0500, Chris Muller wrote:
I wouldn't be surprised if there wasn't more low-hanging fruit like this.
Well done!
Nah, if it weren't for your work no one would have noticed or been curious enough to wonder why less-than (<) could perform that poorly..
DateAndTime class>>#now is purposefully "slow" to assure DateAndTime now < DateAndTime now. Dave, I'm not sure whether you preserved that behavior, if not it might not be a very fair benchmark comparison..
No, I did not preserve that behavior.
Dave
On Mon, Jun 2, 2014 at 9:53 AM, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-cmm.855.mcz
==================== Summary ====================
Name: Kernel-cmm.855 Author: cmm Time: 2 June 2014, 9:53:24.175 am UUID: 478f3548-e587-4dd9-8962-d6ba6dbe2035 Ancestors: Kernel-eem.854
- A simple fix for an 8X performance improvement in DateAndTime>>#< as reported by LXTestDateAndTimePerformance.
=============== Diff against Kernel-eem.854 ===============
Item was changed: ----- Method: DateAndTime>>< (in category 'ansi protocol') -----
- < comparand
- < comparand "comparand conforms to protocol DateAndTime, or can be converted into something that conforms."
| lvalue rvalue comparandAsDateAndTime |
| lticks rticks comparandAsDateAndTime | comparandAsDateAndTime := comparand asDateAndTime. offset = comparandAsDateAndTime offset
ifTrue:
[ lvalue := self.
rvalue := comparandAsDateAndTime ]
ifFalse:
[ lvalue := self asUTC.
rvalue := comparandAsDateAndTime asUTC ].
^ lvalue julianDayNumber < rvalue julianDayNumber or:
[ lvalue julianDayNumber > rvalue julianDayNumber
ifTrue: [ false ]
ifFalse:
[ lvalue secondsSinceMidnight < rvalue secondsSinceMidnight or:
[ lvalue secondsSinceMidnight > rvalue secondsSinceMidnight
ifTrue: [ false ]
ifFalse: [ lvalue nanoSecond < rvalue nanoSecond ] ] ] ]!
ifTrue: [lticks := self ticks.
rticks := comparandAsDateAndTime ticks]
ifFalse: [lticks := self asUTC ticks.
rticks := comparandAsDateAndTime asUTC ticks].
^ lticks first < rticks first
or: [lticks first > rticks first
ifTrue: [false]
ifFalse: [lticks second < rticks second
or: [lticks second > rticks second
ifTrue: [false]
ifFalse: [lticks third < rticks third]]]]
- !
Item was changed: ----- Method: DateAndTime>>= (in category 'ansi protocol') ----- = aDateAndTimeOrTimeStamp self == aDateAndTimeOrTimeStamp ifTrue: [ ^ true ]. ((aDateAndTimeOrTimeStamp isKindOf: self class) or: [aDateAndTimeOrTimeStamp isKindOf: DateAndTime orOf: TimeStamp]) ifFalse: [ ^ false ]. ^ self offset = aDateAndTimeOrTimeStamp offset ifTrue: [ self hasEqualTicks: aDateAndTimeOrTimeStamp ]
ifFalse: [ self asUTC hasEqualTicks: aDateAndTimeOrTimeStamp asUTC ]!
ifFalse: [ self asUTC ticks = aDateAndTimeOrTimeStamp asUTC ticks ]!
squeak-dev@lists.squeakfoundation.org