PackageOrganizerCache
Locked
 
|
Hello,
I'm currently looking at the use of the PackageOrganizerCache in Moose. There was some work in pharo about a new, more performant, better-structured (I think it's the idea ? :)) 'Package system' called RPackage.
So before doing anything, I would like to know more about the use of PackageOrganizerCache: - Why do we use a cache ? I guess this is because accessing directly parent packages of specific classes or methods was to slow using the current package system.
- If this is the good answer :), why was it too long? could another package system (RPackage) solve this problem and avoid us to use a cache ? - For which kind of task is used the packageCache in Moose? I saw that it was used at the import of smalltalk code, to link classes and method to their parent package, is that all ?
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
I do not really know. But this is an important issue.
I experienced some problem when I modify some class extension in Smalltalk, then got some problem when loading back in Moose. Cheers, Alexandre On 27 Oct 2010, at 11:27, Cyrille Delaunay wrote: > Hello, > > I'm currently looking at the use of the PackageOrganizerCache in Moose. > There was some work in pharo about a new, more performant, better-structured (I think it's the idea ? :)) 'Package system' called RPackage. > So before doing anything, I would like to know more about the use of PackageOrganizerCache: > - Why do we use a cache ? I guess this is because accessing directly parent packages of specific classes or methods was to slow using the current package system. > - If this is the good answer :), why was it too long? could another package system (RPackage) solve this problem and avoid us to use a cache ? > - For which kind of task is used the packageCache in Moose? I saw that it was used at the import of smalltalk code, to link classes and method to their parent package, is that all ? > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by cdelaunay
On 27 oct. 2010, at 16:27, Cyrille Delaunay wrote: > Hello, > > I'm currently looking at the use of the PackageOrganizerCache in Moose. > There was some work in pharo about a new, more performant, better-structured (I think it's the idea ? :)) 'Package system' called RPackage. > So before doing anything, I would like to know more about the use of PackageOrganizerCache: > - Why do we use a cache ? I guess this is because accessing directly parent packages of specific classes or methods was to slow using the current package system. > - If this is the good answer :), why was it too long? could another package system (RPackage) solve this problem and avoid us to use a cache ? > - For which kind of task is used the packageCache in Moose? I saw that it was used at the import of smalltalk code, to link classes and method to their parent package, is that all ? Basically, yes, yes, and yes. The current package system (PackageOrganizer + PackageInfo) is reeeally slow for some tasks, like computing package of methods (to detect class extensions), and it really brought down the Smalltalk importer to its knee on even not so large models. The big problem now is linking the package organizer to system events, so that it updates itself whenever a package is added, renamed, removed, changed... This was not done with PackageOrganizerCache because it's a bit difficult and because it was just a workaround at the time. Now RPackage should replace the current organizer and has to take care of such events. It also appear that RPackage initializes itself faster than PackageOrganizerCache (probably because it's more clever in its usage of PackageInfo API). Anyway, it's a problem specific to the Smalltalk importer, not to Moose or Famix in general. -- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by cdelaunay
On Oct 27, 2010, at 4:27 PM, Cyrille Delaunay wrote: > Hello, > > I'm currently looking at the use of the PackageOrganizerCache in Moose. > There was some work in pharo about a new, more performant, better-structured (I think it's the idea ? :)) 'Package system' called RPackage. > So before doing anything, I would like to know more about the use of PackageOrganizerCache: > - Why do we use a cache ? I guess this is because accessing directly parent packages of specific classes or methods was to slow using the current package system. Yes > - If this is the good answer :), why was it too long? could another package system (RPackage) solve this problem and avoid us to use a cache ? yes > - For which kind of task is used the packageCache in Moose? I saw that it was used at the import of smalltalk code, to link classes and method to their parent package, is that all ? Checking extension of a package and package of a class. Stef _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by cdelaunay
On Oct 27, 2010, at 4:48 PM, Simon Denier wrote: > > On 27 oct. 2010, at 16:27, Cyrille Delaunay wrote: > >> Hello, >> >> I'm currently looking at the use of the PackageOrganizerCache in Moose. >> There was some work in pharo about a new, more performant, better-structured (I think it's the idea ? :)) 'Package system' called RPackage. >> So before doing anything, I would like to know more about the use of PackageOrganizerCache: >> - Why do we use a cache ? I guess this is because accessing directly parent packages of specific classes or methods was to slow using the current package system. >> - If this is the good answer :), why was it too long? could another package system (RPackage) solve this problem and avoid us to use a cache ? >> - For which kind of task is used the packageCache in Moose? I saw that it was used at the import of smalltalk code, to link classes and method to their parent package, is that all ? > > Basically, yes, yes, and yes. > > The current package system (PackageOrganizer + PackageInfo) is reeeally slow for some tasks, like computing package of methods (to detect class extensions), and it really brought down the Smalltalk importer to its knee on even not so large models. The big problem now is linking the package organizer to system events, so that it updates itself whenever a package is added, renamed, removed, changed... So far this is not done in RPackage because the event were not there. But now they are available so we should check that. I will check and discuss that with cyrille because this will help us. > This was not done with PackageOrganizerCache because it's a bit difficult and because it was just a workaround at the time. Now RPackage should replace the current organizer and has to take care of such events. It also appear that RPackage initializes itself faster than PackageOrganizerCache (probably because it's more clever in its usage of PackageInfo API). I do not know. So long that I looked at Rpackage. > Anyway, it's a problem specific to the Smalltalk importer, not to Moose or Famix in general. > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
I started to replace PackageOrganizerCache by RPackage. What I did is: -> first Look at all references to PackageOrganizerCache -> replace those refererences by a corresponding use of RPackage -> run tests and fix them one by one I'm in a state where all tests seem to be green. Now I don't know how we want to integrate that. With stephane we talked about having a kind of 'transition state': we would have the possibility to use either the PackageOrganizerCache or either RPackage, so that if something's wrong, we can quickly return to a working version of moose. Or maybe it would be better to integrate that directly ? I guess that there is also some test to make about the performance. By comparing quickly with old result registered in MooseScripts, RPackage seems to be a bit slower than POC.But I should make a more precise comparison using the same machine and vm for both. To load the version using RPackage, in a moose image evaluate: Gofer new squeaksource: 'PharoTaskForces'; package: 'ConfigurationOfRPackage'; load. (Smalltalk globals at: #ConfigurationOfRPackage) loadDefault. Gofer new squeaksource: 'DelaunayTmpStuffs'; package: 'Moose-SmalltalkImporter'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; package: 'Moose-Tests-SmalltalkImporter-Core'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; package: 'Moose-Tests-SmalltalkImporter-KGB'; merge. see http://code.google.com/p/moose-technology/issues/detail?id=414 2010/10/27 Stéphane Ducasse <[hidden email]>
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |