Hi Martin, Some great points.
The kind of bloat I'd like to trim is the overly complex frameworks. This is probably the hardest to cut down though because of API considerations. I suspect that the most egregious cases have grown out of a simple initial model, with overtime new requirements added, so that its kind of grown lopsided and out of proportions. Add a kitchen here, a sunroom there, a new garage... and now you have to go through the basement to have breakfast. Our big advantage today is that presumably we understand how Eclipse is being used (vs. 10 years ago when we'd hope for cleverness and luck). So I'd love to see some simplifying frameworks that still capture a broad usage. Getting things like singletones is a good step. But this is all speaking very generally. The hope is that there are some common simplifying patterns we can apply, but I fear that the reality is that each case will need to be examined invidiually. I don't mind the platform being big if its because its including common pieces that avoid downstream plugins/products from having to duplicate. Its its purpose, provided of course that the likelyhood of reuse is high enough to warrant everyone getting it. Optional packages/plugins are one option but I think the packagings have gotten sufficiently large and complex that its hard to know what you can exclude, as anyone who has tried to build an RCP app which uses IResources can attest to. Wrt the string and image discussion, you're right, I misunderstood :) Regards, Kevin "Oberhuber, Martin" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10/15/2008 05:33 PM Please respond to E4 developer list <[email protected]> To "E4 developer list" <[email protected]> cc Subject RE: [eclipse-incubator-e4-dev] Avoiding Bloat Thanks Kevin. I fully agree that reducing the code bloat is likely the most interesting area. Looking at Winstone [1], "servlet functionality without the bloat that full J2EE compliance introduces", I got the idea that reducing code bloat is likely related to getting rid of less-often-needed functionality. Which is interesting in the context of a component platform like Eclipse. Where does the bloat start? Is Equinox bloated? Likely not, though there exist commercial embedded OSGi implementations like which I think are smaller. Is the core Platform bloated? The Eclipse SDK? The Modeling Package? Ganymede? Galileo? Given that a component platform is made to mix-and match components, it's getting harder and harder to avoid bloat / duplication the more the components are separate from each other. There needs to be constant communication and interaction between the core framework and all adopters in order to reduce bloat. One way of reducing bloat in the large application, is pushing functionality down into the core framework (which might, incidentally, be perceived as making the framework bloated). On the other hand, reducing bloat in the Framework is possible by factoring out functionality into optional modules (which are not always necessarily loaded). But I'm getting too philosophical. To me, the key for avoiding code bloat is providing small but powerful abstractions and programming models in the core framework. And the constant reaching out to the community to actually use the new, modern, flexible frameworks instead of the older style ones... thinking of modern flexible Eclipse core.expressions here, along with Commands and ui.menus, versus the older action framework for instance. Without doubt, e4 with all the e3 compatibility layers will be bloated. What are we going to do to make the e4 core slick, such that people WANT to use the new mechanisms? Strings and Images You probably mis-read me. In my model, images and Strings are not shared at development / install time and are thus not API. But when a bundle gets installed, all those resources are thrown into a common database such that they can be shared at runtime, and they don't need to remain in memory all the time. I'm assuming that from all the NLS Bundles we have in a running Eclipse instance today, typically not more than 20% are ever needed at runtime (and the rest are error messages which are displayed very rarely). Yet their NLS classes are loaded into memory, so the Strings are also loaded - without ever being referenced. Using a database could allow keeping these Strings and images on disk until they are actually needed. I'm not exactly sure what magic technology could be used at install time in order to turn the NLS references we have at compile-time today into database-references at runtime. But it's an interesting thought. And, as a matter of fact there exist classfile rewriters such as RetroWeaver [2] and runtime code weavers such as AspectJ [3], so perhaps it's somehow possible? At least it should be possible if we came up with a different mechanism for referencing externalized resources... [1] http://winstone.sourceforge.net/#whatIs [2] http://retroweaver.sourceforge.net/ [3] http://www.eclipse.org/aspectj/ Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin McGuire Sent: Wednesday, October 15, 2008 4:46 PM To: E4 developer list Subject: Re: [eclipse-incubator-e4-dev] Avoiding Bloat This is a good discussion. Stepping back, I'm seeing three broad topics: 1: Strings (well discussed already) 2: Images Sharing an image makes it API. Thus there is always a "do we want to keep this around forever" discussion. Also, we'd like to remain free to change the contents of the image but there's concern about images re-used in a different/unknown context and whether the change could be bad for the consumer. That said, I think the tendency has been to open up more and more images, with the idea being that they're likely to stick around anyway so we might as well share them. It doesn't address the content change issue though. 3: Code Reducing code bloat has both a positive impact on the size of the SDK (as do the above) but to me, more importantly, a positive impact on the required brain size to program Eclipse. And a positve impact on the maintenance cost, both of the SDK and the downstream plugins. I've always believed that code breeds more code. I was wondering if folks on this thread had specific ideas on simplifying our code weight. That said, I suppose strings and images are an easier place to start. Regards, Kevin [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/15/2008 10:08 AM Please respond to E4 developer list <[email protected]> To E4 developer list <[email protected]> cc Subject Re: [eclipse-incubator-e4-dev] Avoiding Bloat I think something similar already exists in the platform but is internal. I'm not sure how stable/useful it is but Ctrl+Shift+T for "StringPool". Mark. ---------------------------------------------------------- Boris Bokowski <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10/15/2008 09:51 AM Please respond to E4 developer list <[email protected]> To E4 developer list <[email protected]> cc Subject Re: [eclipse-incubator-e4-dev] Avoiding Bloat Eric Moffatt wrote on 10/15/2008 09:36:56 AM: > As far as Strings go Wikipedia indicates that java already does some > form of this through a technique called 'interning', why should we > try to compete? Because there is never an easy answer ;-) ... interned strings use that especially precious "perm space" memory on some VMs. See for example: http://forums.sun.com/thread.jspa?threadID=741223 Boris_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
