On 14.04.2012 23:36, Michaël Michaud wrote: > Hi, > > IMHO, before changing the whole framework, it would be important > to understand where the current slowness comes from.
true, but thinking into the future we probably will have - even more extensions - valuable extensions with inefficient initialize methods - where even if we fix this it'll take time until the changes make it upstream so thinking bigger picture here makes sense. > I think that loading just what is needed should not be too long as the whole > OpenJUMP core loading is quite fast. right > If no solution can be found, I think that it is better to wait a little > at startup time > than when the plugin is used the first time. agreed generally. as we currently see that using oj from a network share makes PLUS unusable for some, i think moving the problem to plugin execution is not helping these cases. > Lazy loading can be great, but I wonder what will happen when it will add a > menu item, a button or a menu while the user is already working... in theory it simply shows up. in praxis we would see ;) .. i start thinking that we could start caching the results of plugin finding and this way reduce the startup time for subsequent runs. on file changes in lib/ext the changed files would be parsed again of course. a similar approach would surely help sextante binding, see my answer to landon. > > If we want a better control on the loading process and on the memory usage, > we may need a plugin manager able to load/unload extensions. not sure about the urgent necessity of unloading here. would be perfect right ;) but i feel that allowing users to profile plugins (en/disabling) and online update/installing is more urgent from my point of view. ..ede ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
