I'm grouping by date a resultset coming from the database, it cointains around 2000 dated objects. It is: myObject groupBy: #date. But turn's out that DateAndTime #= comparison is elegant object-wise but not performance-wise. Because it instantiates several other objects along the way. This is in the milliseconds range, but in the agregate of a couple of thousand of objects, it creates a lot of not-simple-objects (it is, not integers), and maybe because of that it isn't as fast as I'd expect. Did somebody experienced this too? Regards, Esteban A. Maringolo
Yes, Iâve experienced this (in older Pharo versions mind you). We explicitly donât use DateAndTime / Date / Timestamp in such cases but store an integer representation instead. We can always reify that if we need to and still have good comparison speeds. Cheers, Max On 26.03.2014, at 22:21, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I'm grouping by date a resultset coming from the database, it cointains around 2000 dated objects.
It is: myObject groupBy: #date.
But turn's out that DateAndTime #= comparison is elegant object-wise but not performance-wise. Because it instantiates several other objects along the way.
This is in the milliseconds range, but in the agregate of a couple of thousand of objects, it creates a lot of not-simple-objects (it is, not integers), and maybe because of that it isn't as fast as I'd expect.
Did somebody experienced this too?
Regards,
Esteban A. Maringolo
On 26 Mar 2014, at 22:21, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I'm grouping by date a resultset coming from the database, it cointains around 2000 dated objects.
It is: myObject groupBy: #date.
But turn's out that DateAndTime #= comparison is elegant object-wise but not performance-wise. Because it instantiates several other objects along the way.
Not that I want to defend DataAndTime (I didn't implement and I am not using ZTimestamp for nothing), but I fail to see what is wrong with the code, how does it 'create several objects' (in Pharo 3) ? DateAndTime>>#hasEqualTicks: aDateAndTime ^ (self julianDayNumberUTC = aDateAndTime julianDayNumberUTC) and: [ (seconds = aDateAndTime secondsSinceMidnightUTC) and: [ nanos = aDateAndTime nanoSecond ] ] these are all inst vars comparisons.
This is in the milliseconds range, but in the agregate of a couple of thousand of objects, it creates a lot of not-simple-objects (it is, not integers), and maybe because of that it isn't as fast as I'd expect.
Did somebody experienced this too?
Regards,
Esteban A. Maringolo
What version are you using? In Pharo 3 it just checks the identity, species, and then accesses some inst vars. What objects are instantiated? Esteban A. Maringolo wrote
I'm grouping by date a resultset coming from the database, it cointains around 2000 dated objects.
It is: myObject groupBy: #date.
But turn's out that DateAndTime #= comparison is elegant object-wise but not performance-wise. Because it instantiates several other objects along the way.
This is in the milliseconds range, but in the agregate of a couple of thousand of objects, it creates a lot of not-simple-objects (it is, not integers), and maybe because of that it isn't as fast as I'd expect.
Did somebody experienced this too?
Regards,
Esteban A. Maringolo
-- View this message in context: http://forum.world.st/DateAndTime-slow-tp4750964p4750971.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I'm using Pharo 2, a build one month old as much. Date (Timespan)>>#= comparand ^ self species = comparand species and: [ self start = comparand start "start is a DateAndTime" and: [ self duration = comparand duration ]] DateAndTime>>#= other self == other ifTrue: [ ^ true ]. (self species = other species) ifFalse: [ ^ false ]. ^ self asSeconds = other asSeconds and: [ self nanoSecond = other nanoSecond ] And the culprit (I guess): DateAndTime>>#asSeconds "Return the number of seconds since the Squeak epoch" ^ (self - (self class epoch)) asSeconds DateAndTime's class #epoch instantiates two DateAndTimes, one for julianDayNumber zero, and then other for the offset: DateAndTime class>>#epoch "Answer a DateAndTime representing the Squeak epoch: 1 January 1901" ^ (self julianDayNumber: SqueakEpoch) offset: 0. The #asSeconds also incur in DateAndTime subtraction (operand #-), which doesn't seem to be tuned for performance either. Best regards! Esteban A. Maringolo
participants (4)
-
Esteban A. Maringolo -
Max Leske -
Paul DeBruicker -
Sven Van Caekenberghe