Hi list,
I'm creating a GUI where a graph of objects (each one has a unique name) are displayed in a tree view and where each object is added to a local workspace with its name as the binding key. To do this the GUI has a workspace that is created as: self workspace: (Workspace on: '' asValue). and later: self objects do: [:obj | self workspace addLocal: obj name value: obj]. The thing is that for 10 objects the GUI takes 1 second to open (and I'm planning to add hundreds of them). By profiling it I can see that: Workspace>>addLocal: aKey value: anObject forwards to: WorkspaceVariablePool(GeneralNameSpace)>>at: aKey put: aValue | key bind | key := self asKey: aKey. bind := SystemUtils ensureName: key in: self. bind value: aValue. ^aValue which is why it takes so long, since ensureName: newName in: aNameSpace "The binding is assumed to be new--i.e., it does not exist in any NameSpace. Add it to Undeclared." | new old | (aNameSpace asNameSpace includesKey: newName) ifTrue: [^aNameSpace bindingFor: newName]. self modifySystem: [new := aNameSpace asNameSpace createKey: newName value: nil. (old := Undeclared bindingFor: newName) notNil ifTrue: [new value: old value]. aNameSpace asNameSpace simpleAddBinding: new]. ^new I guess I must be missing something, but I can't see why this is really necessary, instead of just having a local dictionary. Any hints are much appreciated. -- Thanks in advance, Andrés _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In general, if you put a name into a namespace, it might be
imported elsewhere, and adding it might then cause other name resolutions
to be different.
Wrap the entire loop in a modifySystem: and you should get much better performance. At 11:58 AM 2009-10-28, andres wrote: Hi list, --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Hi Alan, thanks for the quick response. I agree in what you say about
namespaces, my doubt is why isn't a dictionary used instead of a namespace for storing a workspace local variables. And thanks for your suggestion, it definitely improves performance! Cheers, Andrés Alan Knight escribió: > In general, if you put a name into a namespace, it might be imported elsewhere, and adding it might then cause other name resolutions to be different. > > Wrap the entire loop in a modifySystem: and you should get much better performance. > > At 11:58 AM 2009-10-28, andres wrote: >> Hi list, >> I'm creating a GUI where a graph of objects (each one has a >> unique name) are displayed in a tree view and where each object is added >> to a local workspace with its name as the binding key. To do this the >> GUI has a workspace that is created as: >> >> self workspace: (Workspace on: '' asValue). >> >> and later: >> >> self objects do: [:obj | self workspace addLocal: obj name value: obj]. >> >> The thing is that for 10 objects the GUI takes 1 second to open (and I'm >> planning to add hundreds of them). >> >> By profiling it I can see that: >> >> Workspace>>addLocal: aKey value: anObject >> forwards to: >> >> WorkspaceVariablePool(GeneralNameSpace)>>at: aKey put: aValue >> >> | key bind | >> key := self asKey: aKey. >> bind := SystemUtils ensureName: key in: self. >> bind value: aValue. >> ^aValue >> >> which is why it takes so long, since >> >> ensureName: newName in: aNameSpace >> "The binding is assumed to be new--i.e., it does not exist in >> any NameSpace. Add it to Undeclared." >> >> | new old | >> (aNameSpace asNameSpace includesKey: newName) >> ifTrue: [^aNameSpace bindingFor: newName]. >> self modifySystem: >> [new := aNameSpace asNameSpace createKey: newName value: nil. >> (old := Undeclared bindingFor: newName) notNil >> ifTrue: [new value: old value]. >> aNameSpace asNameSpace simpleAddBinding: new]. >> ^new >> >> >> I guess I must be missing something, but I can't see why this is really >> necessary, instead of just having a local dictionary. Any hints are much >> appreciated. >> >> -- >> Thanks in advance, >> Andrés >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Well, storing variables is what namespaces are for, so it
seems an obvious thing to use. I'm not sure that a dictionary is going to
have all the methods that the compiler and such would expect to find. But
I don't really know.
At 02:42 PM 2009-10-28, andres wrote: Hi Alan, thanks for the quick response. I agree in what you say about --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
> Well, storing variables is what namespaces are for, so it seems an obvious thing to use.
Yes, but it seems to me that a namespace has a superset of the required features (the system cheking, modifying the Undeclared registry, organization, importing from other namespaces, a comment, etc, etc). It looks to me like it is something that does the job, although a refactoring (or even other approach) would fit better. My 2 cents. Cheers, Andrés > I'm not sure that a dictionary is going to have all the methods that the compiler and such would expect to find. But I don't really know. > > At 02:42 PM 2009-10-28, andres wrote: >> Hi Alan, thanks for the quick response. I agree in what you say about >> namespaces, my doubt is why isn't a dictionary used instead of a >> namespace for storing a workspace local variables. And thanks for your >> suggestion, it definitely improves performance! >> >> Cheers, >> Andrés >> >> >> Alan Knight escribió: >>> In general, if you put a name into a namespace, it might be imported elsewhere, and adding it might then cause other name resolutions to be different. >>> >>> Wrap the entire loop in a modifySystem: and you should get much better performance. >>> >>> At 11:58 AM 2009-10-28, andres wrote: >>>> Hi list, >>>> I'm creating a GUI where a graph of objects (each one has a >>>> unique name) are displayed in a tree view and where each object is added >>>> to a local workspace with its name as the binding key. To do this the >>>> GUI has a workspace that is created as: >>>> >>>> self workspace: (Workspace on: '' asValue). >>>> >>>> and later: >>>> >>>> self objects do: [:obj | self workspace addLocal: obj name value: obj]. >>>> >>>> The thing is that for 10 objects the GUI takes 1 second to open (and I'm >>>> planning to add hundreds of them). >>>> >>>> By profiling it I can see that: >>>> >>>> Workspace>>addLocal: aKey value: anObject >>>> forwards to: >>>> >>>> WorkspaceVariablePool(GeneralNameSpace)>>at: aKey put: aValue >>>> >>>> | key bind | >>>> key := self asKey: aKey. >>>> bind := SystemUtils ensureName: key in: self. >>>> bind value: aValue. >>>> ^aValue >>>> >>>> which is why it takes so long, since >>>> >>>> ensureName: newName in: aNameSpace >>>> "The binding is assumed to be new--i.e., it does not exist in >>>> any NameSpace. Add it to Undeclared." >>>> >>>> | new old | >>>> (aNameSpace asNameSpace includesKey: newName) >>>> ifTrue: [^aNameSpace bindingFor: newName]. >>>> self modifySystem: >>>> [new := aNameSpace asNameSpace createKey: newName value: nil. >>>> (old := Undeclared bindingFor: newName) notNil >>>> ifTrue: [new value: old value]. >>>> aNameSpace asNameSpace simpleAddBinding: new]. >>>> ^new >>>> >>>> >>>> I guess I must be missing something, but I can't see why this is really >>>> necessary, instead of just having a local dictionary. Any hints are much >>>> appreciated. >>>> >>>> -- >>>> Thanks in advance, >>>> Andrés >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> -- >>> Alan Knight [|], Engineering Manager, Cincom Smalltalk >>> [hidden email] >>> [hidden email] >>> http://www.cincom.com/smalltalk >>> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |