I found an asymmetrical behaviour in recurrent use where:distinct:sortedBy:descending: compare to the use of recurrent where:
I get use to take a MagmaCollection and extract from it a small subset in a reader. Then I get the reader passed from one object to another one and eventually refined it with another where: message.
Being able to apply recursively where: query from one initial collection is very very handy.
As long as you do that with where: it is fined. You can repeat over and over where query with the same indexes of the initial collection. However when applying with where:distinct:sortedBy:descending: then indexes of the initial collection are lost (expect the one used for the sort). It happens because the sort create a new MagmaCollection
I enclosed there a small fix. I expect it slows down a bit the sort because of the recreated indexes in the new collection. In the other hand, asymmetrical behaviour is not great at all. May be we should have a fast sort (what we have now) and slower sort but with the expected behaviour.
I am curious to read what Chris think about the issue.
Hilaire
'From Squeak3.9 of 26 December 2007 [latest update: #7068] on 4 April 2008 at 3:43:10 pm'!
!MagmaCollectionReader methodsFor: 'private' stamp: 'HilaireFernandes 4/4/2008 15:41'! newReducedReaderOn: attribute makeDistinct: aBoolean | newMc index | "index := self indexNamed: attribute." newMc := MagmaCollection new. "newMc addIndex: index." collection indexesDo: [:each | newMc addIndex: each]. collection isNewCollection ifTrue: [aBoolean ifTrue: [self asSet do: [:each | newMc add: each]] ifFalse: [self do: [:each | newMc add: each]]] ifFalse: [collection load: newMc from: self makeDistinct: aBoolean]. ^ newMc read: attribute! !
On Vrydag, 04 April 2008, Hilaire Fernandes wrote:
I found an asymmetrical behaviour in recurrent use where:distinct:sortedBy:descending: compare to the use of recurrent where:
I get use to take a MagmaCollection and extract from it a small subset in a reader. Then I get the reader passed from one object to another one and eventually refined it with another where: message.
Being able to apply recursively where: query from one initial collection is very very handy.
As long as you do that with where: it is fined. You can repeat over and over where query with the same indexes of the initial collection. However when applying with where:distinct:sortedBy:descending: then indexes of the initial collection are lost (expect the one used for the sort). It happens because the sort create a new MagmaCollection
I enclosed there a small fix. I expect it slows down a bit the sort because of the recreated indexes in the new collection. In the other hand, asymmetrical behaviour is not great at all. May be we should have a fast sort (what we have now) and slower sort but with the expected behaviour.
I am curious to read what Chris think about the issue.
I would like to see an option to enable or enable your enhancement. Speed is IMHO more often more useful than resursive behaviour, so I would vote to have your patch disabled by default.
Brent Pinkney a écrit :
I would like to see an option to enable or enable your enhancement. Speed is IMHO more often more useful than resursive behaviour, so I would vote to have your patch disabled by default.
Yes, depending on the quantity of index in a MagmaCollection, it can be very expensive. I will avoid it myself, I documented this aspect in http://wiki.squeak.org/squeak/5859
Hilaire
I agree with your point about it being asymetrical. And if it were real cheap to build an index, I would be already convinced to make it symetrical.
Yes, depending on the quantity of index in a MagmaCollection, it can be very expensive. I will avoid it myself, I documented this aspect in http://wiki.squeak.org/squeak/5859
But this precisely why the "the minimum needed to satisfy the request" was chosen. If you want to add the additional indexes that are on the original collection, it is easy to do so via #addIndex.
In fact, you could add your own extension if you wanted;
MagmaCollectionReader>>#ensureIndexesOf: anotherMagmaCollection
which would add whatever indexes were needed to make your MagmaCollectionReader have the original indexes of anotherMagmaCollection.
Symmetry in your code would then be achieved by *always* sending this method, which would be a no-op for optimized-Readers.
Regards, Chris
- Chris
magma@lists.squeakfoundation.org
-
Brent Pinkney -
Chris Muller -
Hilaire Fernandes