XE Parser causing long delays & Hangs

It appears my review of XE should have waited until I’ve had more experience with the IDE.

I just filed a QC issue (96552) because I am having a great deal of problems with XE becoming unresponsive.  It appears that when XE parses code in order to inject event handlers or provide code completion, it takes a long time to “think”, and sometimes if just gives up and decides to chew up all your CPU.  The solution to this specific issue seems to be making sure the unit being edited is present in your project as opposed to simply referenced by one of the units in your project.

I am running a stock version of XE with Update 1 now because I uninstalled IDEFixPack and GExperts thinking they might be contributing to the problem (and who can live without the code navigation capabilities of GExperts?).

If you’ve experienced similar issues I would encourage you to vote for QC 96552 and submit your own reports so EMB will give this issue some attention.  Code parsing in the editor has been a problem since D7 days and it scales poorly, so on bigger projects it apparently renders the IDE almost useless.  I have had to wait 5 seconds for the IDE to catch up on the code I’ve typed in because it was busy parsing (I presume), and I’m not a fast  typist.

Tags:

4 Responses to “XE Parser causing long delays & Hangs”

  1. Jeroen Pluimers Says:

    I’ve suffered from this as well since the Kibitz background compiler got introduced (I think it was at or near Delphi 6), but with newer versions of Delphi the speed improvements has been huge.

    In any case, I have the feeling that the slowest Delphi code completion is still a lot faster than the fastest Visual Studio code completion.
    I use both almost daily, and for some things VS2010 is a lot faster, but for others Delphi is.

    –jeroen

  2. noz Says:

    “the slowest Delphi code completion is still a lot faster than the fastest Visual Studio code completion.”
    What?? I don’t complain too much about Delphi code completion, but sometimes it definitely hangs a few seconds (still using D2007). But VS has *always* been instantaneous for me. Also, it’s suggesting to complete something much more often and still it’s faster.
    Of course this is only IMO but I’m curious as to why you’d say the opposite :)

  3. Simon J Stuart Says:

    The most common cause I know of to explain what you’re describing is when you have a large number of entries in the Library Paths.
    This is not so much an IDE “fault” as it is a limitation of HDD performance… though I will certainly concede that the IDE should cache “known files” on the path for faster lookups to be used with Code Completion.

    The reason it seems to be “cured” if you assign the unit to your project explicitly (rather than implicitly through the Library Paths) is because those units are given “priority” when Code Completion is looking for the appropriate unit to parse.

    My general rule of thumb to avoid your issue is as follows:
    1) If it’s not on the Pallet or an Extension to the IDE, keep it out of the global Library Paths
    2) Where above, define the necessary paths within the Library Paths attribute of your Project
    3) For the sake of “shared projects”, use Environment Variables to define a standard name which links to the root path of a library folder. This will enable others involved in your project to store the requisite units in a different location on their system, without having to constantly modify your Project settings in order to locate them.

    This is what I do, and the issue you describe no longer effects me (despite the number of libraries and components I have installed, and the scale of some of the projects I develop)

  4. Warren Says:

    I agree with Simon except I don’t use the library path at all. I leave it at factory defaults. My reasons are not only for IDE performance, but also for project portability, and to keep code completion and error insight from going squirrelly quite as often.

    I want my projects to build on a vanilla installed system without any library path setup. It helps with setting up continuous integration (Jenkins/Hudson) and other things as well as having multi-developer version control on multi projects.

    That means I carefully set up search paths, and put as much of my project units as I can directly into each project, as opposed to using either project search or library paths.

    Warren

Leave a Reply