I’m currently working on large “legacy” LotusScript libraries, which are nested several levels deep. It turns out that the Eclipse-based LS editor (ELSE) is utterly useless for that kind of job, since response times are just plain terrible. Here’s a few examples:- ELSE intermittently freezes for 2 to 3 minutes while I’m in the middle of typing in code.
Saving a single library may take 5+ minutes, as compared to ~1 to 2 seconds for the same library using the classic LS editor (same machine).
Even closing a library (without having modified anything) may take 2+ minutes.
This morning DDE crashed while I was trying to close an (unaltered!) lib.
Are there any general tips on improving DDE/ELSE performance beyond what I mentioned above?
Is there any way to keep ELSE from detecting & highlighting errors on the fly? (My suspicion is that this is what makes it creep.)
Thanks in advance for your time.
[Edit] Forgot to mention that I’m using DDE 8.5.2 with Win7/32 on a pretty fast dual-core processor (native, no VM) equipped with 4 GiB + a fast HD drive.[/Edit]
If you can merge any of these libraries, things will work more smoothly. We often see apps with way too many, which is a problem with performance when executing also – not just for editing.
I’ve sent a query to the people who work on this editor to ask whether there’s any benefit to using 8.5.3. I’ll post here if I get an answer.
First of all, thanks a lot for taking the time to respond!
Yes, I’ve tried to reduce the number of libraries. Also, it appears that it is better to “daisy-chain” libraries rather than “paralleling” them. For example, instead of having agent X use libs A and B, where A uses C and B uses C, it is better to have X use A, A use B and B use C. This can lead to a bad architecture, so noone would probably do that in other programming languages, but in LS it loads faster – for whatever reason.
Unfortunately, both approaches – reducing the number of libs and daisy-chaining them – are of limited use when libraries are deeply tied into the design of an existing large application, where any such change can have a zillion side effects.
I’m wondering why the classic LS editor/compiler is so much faster. (Mind you, 1 to 2 seconds to re-compile & save a lib, vs. 5+ minutes with ELSE.) What makes ELSE so terribly slow in some cases? Is on-the-fly error detection the main culprit, as I’m suspecting? Or is it something else? Or a combination of effects? Whatever the reason(s), are there any [hidden] settings that can speed it up?
Last but not least: I’m a fan of ELSE. It’s really a big leap forward in terms of IDE usability. However, I’d be more than willing to trade off some of its nice features for an acceptable performance.
…and I think they’re working on improving it and may already have done so. But it also has to do more work, because it’s letting you update a library and have the changes show up in some other code you’re editing at the same time, and providing the content assist for custom classes, and recalculating the navigation on the fly as you type, and so on. Plus it’s in Java rather than C. So it’ll never be as fast as the core editor, but I find it a lot easier to use overall and I code faster with it, which is the key criterion for me.
I’ve noticed a lot of things seem to take a lot longer when you’re in the “all code” view as opposed to zoomed in to a particular function or class.
It shouldn’t be too hard to merge libraries without disturbing the architecture. It’s just a matter of choosing the right ones to combine that would make some sort of sense.
I don’t know why making the stack deeper rather than broader should make a difference, unless there’s still some >O(n) stuff going on about comparing the contents of each library with every other library loaded by the same script.
It would probably help to minimize the amount of stuff you declare as public. This is also a good idea from a design perspective anyway; minimize your interface.
I’ve tried all of your suggestions, plus my own. It turned out that merging libs (if possible, as discussed before) and daisy-chaining them were the only two options that helped to a certain extent. (Minimizing the interface by declaring things as Private is something I usually do as much as possible anyway.)
Totally agree with you that ELSE is much easier to use than the classic editor… as long as it doesn’t have me wait 5 minutes to save a library of course.
BTW, I think the Eclipse Java editor is implemented in Java as well – correct me if I’m wrong. Yet its responsiveness is substantially faster than ELSE’s, although it does have at least as many bells and whistles. Which makes me confident that there is sufficient room for improvement
