I agree code bloat is a big problem, and it gets worse every year (Eclipse SDK size is 37MB/55MB/87MB/155MB in 1.0/2.0/3.0/3.4 respectively). More importantly for this stage in e4, it's not something that's easily optimized later, unlike strings and images. Here are some thoughts on ways to reduce code bloat:
- Be more cautious about introducing API. We have lots of bloat from releasing multiple attempts at a given API, which we then need to support forever and can never remove. The common pattern is that we introduce API in release N. Clients only start heavily adopting the API after release N, and this feedback often results in API changes being needed in release N+1 (rinse, repeat). In more recent releases we have become more aggressive at pulling back API that wasn't ready or didn't have sufficient client feedback, to avoid having to indefinitely support API mistakes and limitations. I'd like to see this happen in e4 too. Go wild early on in the development cycle and add what you want, but as the release approaches, only "graduate" API that is proven. I would even advocate some kind of review by project leads for any significant new API, where the API designer has to demonstrate that the API is platform quality, is thoroughly documented, and has multiple clients using it before it gets approved for release as real API. - Do regular code weeding. As code is developed, there always accumulates dead code, images, and other resources that were used for awhile and then no longer used. We should use coverage analysis and other tools to root out and remove unused code/images/strings on a regular basis. This often happens when classes are copied and the new user only uses a subset of the copied functionality. - Cap and trade. This might be a bit over the top, but I have wondered about having a quota on plug-in or component sizes such that they can only grow by so much in a given release. Extra growth can be compensated by making reductions elsewhere. I don't expect this idea to be too popular, but what I'm looking for here is some incentive for developers to avoid bloat. Often there is very little incentive for a developer to avoid bloat, and in a crunch it's too easy to copy wads of code from other plug-ins to get the job done. Or, a large third party library will be added because using some small portion of it will save a bit of work. Code hygiene work such as the weeding mentioned above are also the first things to get dropped when people become busy. It seems without a concrete motivation to avoid bloat, it will inevitably occur. John Kevin McGuire/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/15/2008 10:45 AM Please respond to E4 developer list <[email protected]> To E4 developer list <[email protected]> cc 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
