On 26 Mar 2014, at 22:21, Esteban A. Maringolo <[email protected]> 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
>
