- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] DateAndTime>>#= slow?

by Esteban A. Maringolo

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

March 27, 2014

DateAndTime>>#= slow?

by Stephan Eggermont

DateAndTime is a very good candidate for some slot-tricks, and should probably be a value object. Stephan

March 26, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Paul DeBruicker

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.

March 26, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Sven Van Caekenberghe

On 26 Mar 2014, at 22:21, Esteban A. Maringolo <emaringolo(a)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 >

March 26, 2014

Re: [Pharo-dev] Replacing SBCI buttons in Nautilus.

by phil＠highoctane.be

Instead of using PluggableButtonMorphs, you can try with ButtonModels (the Spec way). Or use a horizontal spacefill. I'll have a look tomorrow. Phil On Wed, Mar 26, 2014 at 10:17 PM, Stephan Eggermont <stephan(a)stack.nl>wrote: > Interesting enough, a PluggableButtonMorph does not center the label. > I've improved the layout by adding a space, but for correct (optical) > alignment, the I needs to move about half a space to the right, > and the C needs to move a few pixels to the left. > > Even though a PluggableButtonMorph has lots of different ways to > set colors, I've not found one that works. Themability is nice, but > it should check for and respect overrides. > > In 30803, without Philippe's slices, with the three themes: > >

March 26, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Max Leske

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(a)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 >

March 26, 2014

Re: [Pharo-dev] Replacing SBCI buttons in Nautilus.

by Stephan Eggermont

https://pharo.fogbugz.com/default.asp?13137 Name: SLICE-Issue-13137-Replace-SBCI-buttons-StephanEggermont.1 Author: StephanEggermont Time: 26 March 2014, 10:30:33.195511 pm UUID: 39080266-ad51-43f9-8ab4-5afe636d7372 Ancestors: Dependencies: Nautilus-StephanEggermont.709 Replace the bitmap-backed buttons through simpler ones

March 26, 2014

DateAndTime>>#= slow?

by Esteban A. Maringolo

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

March 26, 2014

Re: [Pharo-dev] Replacing SBCI buttons in Nautilus.

by Stephan Eggermont

Interesting enough, a PluggableButtonMorph does not center the label. I've improved the layout by adding a space, but for correct (optical) alignment, the I needs to move about half a space to the right, and the C needs to move a few pixels to the left. Even though a PluggableButtonMorph has lots of different ways to set colors, I've not found one that works. Themability is nice, but it should check for and respect overrides. In 30803, without Philippe's slices, with the three themes:

March 26, 2014

Replacing SBCI buttons in Nautilus

by Stephan Eggermont

Iâve been inspired by Philippeâs work on the UI and spend the afternoon replacing the SBCI bitmapped-backed buttons by normal ones. Stephan

March 26, 2014