RAD Studio XE7 Enterprise, Update 1 – Out of memory

RAD Studio XE7 Enterprise, Update 1 – Out of memory

Just to clarify how extensive my memory issues are… I often have to compile at least three of these apps when testing changes.  The server, the admin app, and the truck app.  

I can currently compile 2.5 apps before I have to restart the IDE:P

Switching between two apps, the leak is slightly slower – but I will run out.  

I usually end up doing something like this: 

– Exit IDE, Restart IDE

– Compile the two apps I won’t be debugging,

– Exit IDE, Restart IDE

– Compile the app I plan to debug

– Exit IDE, Restart IDE, Start the other two apps outside the debugger.

– Run the app I plan to debug and hope the debugger doesn’t die on continue from breakpoints

…and that’s how the day passes… Dozens and dozens of restarts… and that’s on a good day.

Edit: IDE tweaks:

* No Castalia. 

* -noparser on command line

* Error Insight disabled

I certainly hope you are addressing this for the next major release, Marco Cantù 

30 thoughts on “RAD Studio XE7 Enterprise, Update 1 – Out of memory

  1. No IDE Fix Pack? Is MSBuild any better? Checking that MSBuild box helped me compile a large IOS app when it wouldn’t compile anymore. It wasn’t 2 million lines though.

  2. I configured the Release and Debug configurations so that the Relase always uses MSBuild (Note that it is vital to have different DCU folders for Release and Debug for that). Then I switch only that project to Debug which I am actually debugging. Not perfect, I know, but it might help.

    Another idea: Can you use an independent instance of Delphi for each project? Never tried myself, though.

  3. Uwe Raabe We use Continua CI and build releases directly from the repository. I have not tried the multiple IDE, but expect it to be troublesome in several areas. Shared projects files, shared rc to res files being rebuilt, shared source modification and history, editing or setting breakpoints in the right file in the wrong IDE, debugger issues, etc.

    I have tried using MS Build configs, but it is cumbersome, and I miss out on hints and warnings, and it’s not for debugging.

  4. Lars Fosdal Are those projects you are building part of same project group? From my experience Delphi caches all projects in same group. I don’t have large projects but I can successfully simulate OOM erros with my library that has about 20 test projects included, if I build them all Delphi usually crashes.

    If you close project (project group) after build cache will be cleared. so maybe you can save yourself from restarting Delphi.

    Note: last Delphi version I have tested and where I could reproduce above is XE7.

  5. Dalija Prasnikar – I’ll link my video in the comments on that QP issue.  I’ll try the close project group – but – it still doesn’t solve the OOM issue when building three apps.

  6. Lars Fosdal You would have to build first app, then close Project Group, then build second app, then close, then build third. Build All is recipe for disaster.

    If you can successfully build several apps without OOM you can build them together, then close, then build the rest… 

  7. Lars Fosdal With or without Castalia 😛

    BTW, does closing Project Group help in your case. Not that it is complete solution to the issue, but it is faster workaround than restarting complete IDE. 

  8. /nocastalia /noparser

    Error Insight off

    I remember being able to compile 5-6 apps in the earlier XE versions.

    Closing and reopening the project group does help – but – it’s not what I want.  Hopefully, this will be addressed eventually – preferably before compilation is limited to 0.9 applications.

  9. Lars Fosdal I think that IDE OOM is currently the most serious issue. I also hope it will be solved soon, even though I am not experiencing it myself. But I can imagine the pain for users with large codebases.

Leave a Reply