Should I be doing any periodic cleanup on my IDE (Embarcadero RAD studio)?

Question

It seems like over time Embarcadero RAD Studio (I use XE4 Starter for programming Delphi) has gotten more and more sluggish. I know with other IDE's I've used sometimes you end up with bloat and detritus of temp files and cache files and other unneeded things the IDE generates, and periodically it can help to manually go in and clean those things up.

Are there any particular file removal, or other IDE maintenance a programmer should do periodically to keep RAD Studio running smoothly at peak efficiency?

Answer 1

There are really many angles to how the IDE performance is affected. And there's essentially two levels to look at it on: What's installed in the IDE, and what's required by your immediate project.

IDE Maintenance

There's not necessarily anything you should have to do on a regular basis to your IDE. However, you should make sure that your library path is up-to-date. This is one of the most common things I ever need to manage in the IDE.

Then there's the third-party libraries, components, add-ons and fix-packs that you can install onto the IDE. Each one of these has the possibility of slowing things down, so make sure you only have things installed that you actually use.

Project Maintenance

Performance of the IDE isn't usually hindered by maintenance of a project. However, a very large complex project (or project group) may wind up slowing it down. Cleaning of the DCU files of a project shouldn't be necessary on any regular basis, but can often help clean up and forcefully re-compile anything which the IDE may have neglected to keep up to date. I've seen issues which were solved by deleting DCU files and recompiling them. Remember, DCU files are essentially compiled code, and is mostly for the purpose of caching the compilation so that it only needs to compile those units which have changed since the last compilation. So, cleaning up the DCU's will result in the next compilation taking a little longer than usual. Still, not much worth the pain.

Conclusion

There's a batch file I use commonly to clean up unnecessary files in different project folders. That batch file is scripted like below, and simply deletes any temporary files I don't need to keep around. But it's only needed on rare occasions when I'm cleaning up the source, and not really on any schedule.

del *.dcu
del *.dof
del *.dsk
del *.identcache
del *.local
del *.~*
del *.cfg
del *.dsm
del *.rsm
del *.otares

Note that the same or similar can be accomplished by choosing the "Clean" option in the IDE for any given open project.

Edit

You can also accomplish best IDE performance by keeping track of how your project interacts with the IDE. For example, components or controls which perform heavy actions (such as database connections with data aware controls).

Answer 2

OP hasn't characterized the nature of HOW the IDE "has gotten more and more sluggish," so anything anybody says here is little more than random speculation.

First off, I've never used the Starter Edition of Delphi. Aside from that, I've never noticed any particular slow-down on different versions, other than what you'd expect from normal stuff. That is, if you load bigger files, it can take longer to do stuff in the IDE. More installed libs and components take longer to load at startup, but impose negligible impact inside the designer. Deleting files like those above can slow down builds because the compiler needs to reproduce them; but if you're not using that project, then there shouldn't be any impact whether they're present or not. And poorly designed components can take a toll on IDE performance.

It's entirely possible there may be some optimizations turned off in the Starter Edition, or things missing that might result in performance hits over time. It's not as "feature complete" as the full IDE, although I've never investigated the differences. I just stick to full released products because I use them for production work.

Also, maybe it's time you upgraded your computer. You could be dealing with limitations in virtual and physical memory that have nothing to do with Delphi, which is a rather large app in its own right. I run Delphi inside of a VMWare VM on a MacBook Pro, and it works fine unless the memory gets tight, then it can slow way down. (Again, without more specifics, it could really be tons of different things.)