Hi Mines game got really sluggish on a old laptop with i3 processor. I tracked it down to this method where we copy protoTile instance variable
MineBoard>>adjustTiles "reset tiles"
| newSubmorphs count r c |
submorphs do: "clear out all of the tiles." [:m | m privateOwner: nil].
newSubmorphs := OrderedCollection new.
r := 0. c := 0. count := columns * rows.
1 to: count do: [:m | newSubmorphs add: (protoTile copy *"Change this to MinesTile new to speed up"* position: self position + (self protoTile extent * (c @ r)); actionSelector: #tileClickedAt:newSelection:modifier:; arguments: (Array with: (c+1) @ (r+1)); target: self; privateOwner: self). c := c + 1. c >= columns ifTrue: [c := 0. r := r + 1]]. submorphs := newSubmorphs asArray.
Here is MessageTally:
[ 67.5% {8826ms} MinesBoard>>adjustTiles [ 67.5% {8824ms} MinesTile(Morph)>>copy [ 67.5% {8824ms} MinesTile(Object)>>veryDeepCopy [ 66.6% {8713ms} DeepCopier>>fixDependents [ 66.6% {8713ms} WeakIdentityKeyDictionary(WeakKeyDictionary)>>associationsDo: [ 64.3% {8404ms} primitives [ 2.2% {289ms} [] DeepCopier>>fixDependents [ 1.7% {222ms} DependentsArray>>do: [ 1.1% {139ms} primitives
Best, Karl
Hi
On 1. Mar 2023, at 22:23, karl ramberg karlramberg@gmail.com wrote:
Hi Mines game got really sluggish on a old laptop with i3 processor. I tracked it down to this method where we copy protoTile instance variable
MineBoard>>adjustTiles "reset tiles"
| newSubmorphs count r c |
submorphs do: "clear out all of the tiles." [:m | m privateOwner: nil].
newSubmorphs := OrderedCollection new.
r := 0. c := 0. count := columns * rows.
1 to: count do: [:m | newSubmorphs add: (protoTile copy "Change this to MinesTile new to speed up" position: self position + (self protoTile extent * (c @ r)); actionSelector: #tileClickedAt:newSelection:modifier:; arguments: (Array with: (c+1) @ (r+1)); target: self; privateOwner: self). c := c + 1. c >= columns ifTrue: [c := 0. r := r + 1]]. submorphs := newSubmorphs asArray.
So is the protoTile Morph supposed to have depdendents or submorphs itself? Morphs seem a tad heavy to copy en masse. Non-Morph objects are pretty lightweight (see shallowCopy/postCopy)
Given these tiles ought to be quite independent and small, I really do not see why driving them through the dependents fixup.
So one could simply really use a new, empty tile.
That said, why are the "old" ones thrown out, anyway?
I've skimmed the code and am actually puzzled. The dependency-fixup is roughly the same age as the Mines game. So either the Mines-Game author did not notice that slowdown or Instance creation was waaaaaay more expensive back then...
Best regards -Tobias
Here is MessageTally:
[ 67.5% {8826ms} MinesBoard>>adjustTiles [ 67.5% {8824ms} MinesTile(Morph)>>copy [ 67.5% {8824ms} MinesTile(Object)>>veryDeepCopy [ 66.6% {8713ms} DeepCopier>>fixDependents [ 66.6% {8713ms} WeakIdentityKeyDictionary(WeakKeyDictionary)>>associationsDo: [ 64.3% {8404ms} primitives [ 2.2% {289ms} [] DeepCopier>>fixDependents [ 1.7% {222ms} DependentsArray>>do: [ 1.1% {139ms} primitives
Best, Karl
On Wed, Mar 1, 2023 at 11:38 PM Tobias Pape Das.Linux@gmx.de wrote:
Hi
On 1. Mar 2023, at 22:23, karl ramberg karlramberg@gmail.com wrote:
Hi Mines game got really sluggish on a old laptop with i3 processor. I tracked it down to this method where we copy protoTile instance
variable
MineBoard>>adjustTiles "reset tiles"
| newSubmorphs count r c |
submorphs do: "clear out all of the tiles." [:m | m privateOwner: nil].
newSubmorphs := OrderedCollection new.
r := 0. c := 0. count := columns * rows.
1 to: count do: [:m | newSubmorphs add: (protoTile copy "Change this to MinesTile new to speed up" position: self position + (self protoTile extent * (c @ r)); actionSelector: #tileClickedAt:newSelection:modifier:; arguments: (Array with: (c+1) @ (r+1)); target: self; privateOwner: self). c := c + 1. c >= columns ifTrue: [c := 0. r := r + 1]]. submorphs := newSubmorphs asArray.
So is the protoTile Morph supposed to have depdendents or submorphs itself? Morphs seem a tad heavy to copy en masse. Non-Morph objects are pretty lightweight (see shallowCopy/postCopy)
Given these tiles ought to be quite independent and small, I really do not see why driving them through the dependents fixup.
So one could simply really use a new, empty tile.
That said, why are the "old" ones thrown out, anyway?
I've skimmed the code and am actually puzzled. The dependency-fixup is roughly the same age as the Mines game. So either the Mines-Game author did not notice that slowdown or Instance creation was waaaaaay more expensive back then...
SameGame and Mines have some really peculiar code. And there are subclassing and reuse instance variables that make it hard to follow. If you run a course on refactoring, it could be a good introduction project to document and make sense of this code :-D
Best, Karl
Best regards -Tobias
Here is MessageTally:
[ 67.5% {8826ms} MinesBoard>>adjustTiles [ 67.5% {8824ms} MinesTile(Morph)>>copy [ 67.5% {8824ms}
MinesTile(Object)>>veryDeepCopy
[ 66.6% {8713ms} DeepCopier>>fixDependents [ 66.6% {8713ms}
WeakIdentityKeyDictionary(WeakKeyDictionary)>>associationsDo:
[ 64.3% {8404ms} primitives [ 2.2% {289ms} []
DeepCopier>>fixDependents
[ 1.7% {222ms} DependentsArray>>do: [ 1.1% {139ms} primitives
Best, Karl
squeak-dev@lists.squeakfoundation.org