28

I have a few large (~600k lines of code) Delphi projects. They include some custom components which our team has developed.

Often, when I call up code completion with ctrl+space or just by pressing ".", the IDE locks up and thinks really hard for a long time. Sometimes the delay can be a full minute, or more. Other times, it pops up immediately with suggestions.

What factors influence the performance of intellisense in Delphi? Is there any way I can improve this performance?

My best solution so far is to turn off the automatic completion, and use ctrl+space when I need to meditate quietly for a minute or so.

I can't help but mention that VS2005, VS2008, and XCode all seem to give virtually instant intellisense feedback (although I've never tried it on a project this large).

As an alternative, I've offered this suggestion.

Warren P
  • 65,725
  • 40
  • 181
  • 316
JosephStyons
  • 57,317
  • 63
  • 160
  • 234
  • this interests me very much. I remember that the . or Ctrl+Space used to work perfectly well several years ago. I think it was Delphi 7, certainly Delphi 5, in which the delay was hardly discernible. I loved it. But then the D2005 came along and that's when I experienced terrible problems with this feature. What changed? Why did they change it? – Peter Perháč May 22 '09 at 15:14
  • 2
    Good question. It became almost unusable for me on larger projects - reluctantly I turned it off and it's a shame because the online help is bitty and distracting and cumbersome too - it's usually quicker/more direct to just Google for help in all honesty. I'd love to be able to use Ctrl-Space again, it was very useful. – robsoft May 22 '09 at 15:54

6 Answers6

14

Delphi Code Insight invokes the compiler dll to do a custom compile when the user requests Code Insight (Ctrl+Space, '.', etc). This custom compile does a build in the unit and skips over codegen, linking, etc until it reaches your current offset in the file buffer. With this in mind, the unit list that the compiler sees before it gets to your current position will play a large factor in determining the speed of the Code Insight operation. There may be a unit (or multiple units) that are causing a hefty file system dependency, etc. It's quite possible that reordering the uses clause, refactoring the uses clause to be in multiple files, or removing units in the uses clause that aren't necessary for your current unit to compile may improve performance. Additionally, using packages or shortening your unit search path may improve CI response time.

Adam Markowitz
  • 12,919
  • 3
  • 29
  • 21
  • 1
    Interesting answer, thank you! Some food for thought there. :-) – robsoft May 22 '09 at 15:56
  • 1
    That is interesting indeed... but I should point out that a FULL BUILD of the application (with our famously fast compiler, yay) takes about 1 minute... and I've had code completion take longer than that. – JosephStyons May 22 '09 at 18:08
  • If you do a full rebuild (which generates .dcus to disk) does that help CI performance? Also, do you use packages or is it a monolithic .exe? – Adam Markowitz May 22 '09 at 19:04
  • Monolithic EXE, and a full build does not really seem to help much, no. – JosephStyons May 27 '09 at 13:51
7

Be sure to explicitly include all the units(*) used by your project in the dpr.
Do not rely on the search path to find a unit called from another unit, add it to the dpr. The dpr will be much longer but all the compilation related things will be faster, including code-insight.

(*) not the units of the installed components.

Adam Markowitz
  • 12,919
  • 3
  • 29
  • 21
Francesca
  • 21,452
  • 4
  • 49
  • 90
  • This actually seems to help quite a bit... ctrl+f12 brings up an unsightly list of units that are not specific to the project... but I can live with that. – JosephStyons May 27 '09 at 13:59
  • 1
    Besides search paths inside the project, the other terrible lags come in if you have a giant Library Path. – Warren P Feb 03 '12 at 14:01
  • What greatly helped me in the similar case - to **remove unused units** from "uses" sections and move units wherever possible from "interface" to "implementation". 346kLoc project compilation time went down from 70 sec to 8.8 sec. This directly influenced Code Completion. Now it's almost instant. – Kromster Aug 12 '17 at 11:42
4

I don't know which version you are using, but much faster code completion is one of the things I like most about Delphi 2009.

Wouter van Nifterick
  • 23,603
  • 7
  • 78
  • 122
3

This is a long-standing issue with Delphi, and I had to resort to turning off automatic completion. After working that way for a while, I was very happy with it. Even if it only takes a fraction of a second, having the IDE lag my typing was disconcerting and interrupted my flow. Much nicer with the automatics off, IMO.

dwc
  • 24,196
  • 7
  • 44
  • 55
  • can't agree with not using `the automatics`... – Peter Perháč May 22 '09 at 15:12
  • 1
    MasterPeter: each to his own, I'm afraid. When I know what I want I'm much faster typing it than having a pause and then picking. When I don't know what I want I certainly know it, and am perfectly capable of typing Ctrl+Space to get some help. – dwc May 22 '09 at 15:56
  • On small projects, I have found it to be superb; once I learn how it works I can use the code templates and auto-completion to great advantage. That makes the poor performance in a large project all the more frustrating. – JosephStyons May 22 '09 at 18:18
2

I just came across this problem myself, I fixed it by removing a dead network link from my environment library path. Solved my issue 100%.

0

Do you include the sources directories for your teams custom components to be in the library path? It would be interesting to see the speed difference if only the component DCU files are in the library path, versus having the source files there too.

mjn
  • 36,362
  • 28
  • 176
  • 378