Requested for IDE to support more RAM (vote/discuss if you care)

[Tommi Prami 131]

https://quality.embarcadero.com/browse/RSP-41803

-Tee-

Edited June 6, 2023 by Tommi Prami
maybe better English

[Lars Fosdal 1793]

From https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Extending_the_IDE_Using_the_Tools_API

 

 

The 32-bit IDE is already large address space enabled.

[Lars Fosdal 1793]

Since Seattle

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What's_New_in_Seattle

[Tommi Prami 131]

On 6/6/2023 at 9:08 AM, Lars Fosdal said:

From https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Extending_the_IDE_Using_the_Tools_API

 

 

The 32-bit IDE is already large address space enabled.

Interesting.

I got out of memory at 2GB and never seen higher memory usage than 2GB, 

Then it must be some plugin I use, Like GExperts... 

[Tommi Prami 131]

OK,

Tested again, and it seems that I was barking at wrong tree here. I am not really fan of this new taksmanager. Should start to use pRocess Explorer aggain from SysInternals.

Task manager It shows total memory of the process tree, so ide used little more than 1Gb of memory after it died. LSP processes used total of about gig. So total memory consumption peaked around 2Gb maybe slightly over, hard to tell, but it does not matter.

This time I did not get Out of memory, butr IDE used all handles, and after that it ran for awhile, and just vanished.

So memory is not the (only problem), tested this with opening lot of forms. Sometimes you need to go lot of forms through and it is hard to remember which are done and which are not, so... But have to do it in batches anyway, because IDE really start to crawl pretty soon when opening lot of forms. 
 

-Tee-

[Lars Fosdal 1793]

Do you use LiveBindings?

I don't.

[Dalija Prasnikar 1404]

59 minutes ago, Tommi Prami said:

Task manager It shows total memory of the process tree, so ide used little more than 1Gb of memory after it died. LSP processes used total of about gig. So total memory consumption peaked around 2Gb maybe slightly over, hard to tell, but it does not matter.

LSP is separate process and it's memory consumption does no affect the IDE. Extracting that functionality outside and reducing IDE memory footprint was one of the reasons LSP was introduced in the first place.

59 minutes ago, Tommi Prami said:

This time I did not get Out of memory, butr IDE used all handles, and after that it ran for awhile, and just vanished.

There is known GDI handle leak in Parnassus Navigator https://quality.embarcadero.com/browse/RSP-40986

 

Also IDE is using a bit more GDI handles than it used to and it seems that it has some caching issues, where it caches the component icons but it does not have a cache limit and it does not release those that were not accessed in for some period of time. Opening plenty of forms and accessing many different components during design time can hit GDI handle limit. AFAIK you can increase that limit (I never had issues so I never tried it) https://stackoverflow.com/questions/38612364/how-to-increase-the-maximum-amount-of-gdi-object-for-windows-10

[Tommi Prami 131]

14 minutes ago, Dalija Prasnikar said:

LSP is separate process and it's memory consumption does no affect the IDE. Extracting that functionality outside and reducing IDE memory footprint was one of the reasons LSP was introduced in the first place.

There is known GDI handle leak in Parnassus Navigator https://quality.embarcadero.com/browse/RSP-40986

 

Also IDE is using a bit more GDI handles than it used to and it seems that it has some caching issues, where it caches the component icons but it does not have a cache limit and it does not release those that were not accessed in for some period of time. Opening plenty of forms and accessing many different components during design time can hit GDI handle limit. AFAIK you can increase that limit (I never had issues so I never tried it) https://stackoverflow.com/questions/38612364/how-to-increase-the-maximum-amount-of-gdi-object-for-windows-10

That what I tried to say, was not very clear tough, that since LSP is separate process, it does not matter in this case. New Task manager groups them together, so I as previously looking at wrong thing, total memory consumption, instead of just IDE. Therefore jumped into conclusions.

Voted for Navigator GDI leak report, good to know. Thanks.

 

-Tee-

[David Heffernan 2353]

Imagine not being able to make a 64 bit IDE

[Brandon Staggs 285]

3 hours ago, David Heffernan said:

Imagine not being able to make a 64 bit IDE

Yeahbut, do we really need it? I want it, but the reality is that Emba dev resources are very limited. Yes yes, we should not have to choose, but, since somebody does have to choose, would you choose a 64-bit IDE project and all that entails, introducing all those new bugs that will inevitably take several releases to find out and (maybe) fix, or would you choose something else? I would not make 64-bit the priority. They still have incorrect mac header conversions they haven't dealt with despite reports. etc.

 

I would also not make MDI support in VCL Styles a priority, as they seem to be doing now, but perhaps that goes to show, you have to have a big support account and a direct line to product management to get what you want worked on. That's just the cynic in me though. I can't imagine why someone thinks putting resources to enhancing MDI support is the way forward for Delphi, but they think it is so important they are blogging about it.

[FabDev 8]

On 6/8/2023 at 12:46 PM, David Heffernan said:

Imagine not being able to make a 64 bit IDE

Yes I really need it. With an old project with several million lines of code I need to restart more than 20 times a day (Out of memory, black screen etc.) . And sometime it's can corrupt my sources !

We are In 2023 : A 64 bits IDE should be the priority !

Edited June 9, 2023 by FabDev

[David Heffernan 2353]

On 6/8/2023 at 2:54 PM, Brandon Staggs said:

 

I would also not make MDI support in VCL Styles a priority, as they seem to be doing now,

Ironically I'd benefit from this but I agree it seems like an odd change of tack having refused to entertain MDI for years now. 

[David Heffernan 2353]

On 6/8/2023 at 2:54 PM, Brandon Staggs said:

Yeahbut, do we really need it?

Given the number of people that struggle without of memory errors, then I'd say the answer is yes. 

[Lars Fosdal 1793]

On 6/9/2023 at 3:57 PM, David Heffernan said:

Ironically I'd benefit from this but I agree it seems like an odd change of tack having refused to entertain MDI for years now. 

Especially when you consider that MS has abanoned it themselves, not updating the styling for MDI.

I wrote a successful MDI app back thirty years ago.  I would not have chosen MDI for that app today.

[David Heffernan 2353]

33 minutes ago, Lars Fosdal said:

Especially when you consider that MS has abanoned it themselves, not updating the styling for MDI.

I wrote a successful MDI app back thirty years ago.  I would not have chosen MDI for that app today.

What's the way to replicate MDI like behaviour in VCL today? 

[Lars Fosdal 1793]

@David Heffernan

20ish years ago, we replaced it with a toolbar-like main window and floating windows with "magnetic" edges.  

But - the floating approach became less sexy when you no longer could control the window size/position of other apps.

Today, it would probably have been based on larger windows, with multi layer panels/grids.  It depends a lot on your use case.

The current apps - which are WMS related - use a navigator sidebar/menu and "virtual tabs".

 

The drawback of MDI was a lot of space went to borders and title bars.  You could work around that, but why do that when you can just as well do panels/grids/splitters?

Also - what if MS decides to yank out MDI completely? It is, after all, deprecated.

 

[PeaShooter_OMO 11]

5 minutes ago, David Heffernan said:

What's the way to replicate MDI like behaviour in VCL today? 

I was wondering the same thing. Is it not automatically considered to be MDI the moment you have resizable/movable forms as child windows inside a "main" form?

For instance programs like Photoshop have multiple documents but the moment you "undock" it from the Tab interface it becomes an uncoupled form outside the main form. Firefox acts similarly but an uncoupled document becomes another instance of Firefox.

 

We made programs that have multiple forms inside the main form but they never were "documents" but rather functionality forms and they never were movable/sizable and had no caption bars.

 

I suppose I digress from the topic here.

[Brandon Staggs 285]

On 6/12/2023 at 2:06 AM, PeaShooter_OMO said:

Is it not automatically considered to be MDI the moment you have resizable/movable forms as child windows inside a "main" form?

No, not really. MDI is a specific set of API. https://learn.microsoft.com/en-us/windows/win32/winmsg/multiple-document-interface

 

Lots of apps use docking systems, but that is distinct from MDI.

[Brandon Staggs 285]

On 6/12/2023 at 1:47 AM, David Heffernan said:

What's the way to replicate MDI like behaviour in VCL today? 

I think you'd have to define the subset of behavior you want replicated. Generally panels with splitters, I would think, moving up to a docking system if something more configurable is desired. Personally, I am still using (heavily extended and modified) AQDocking in a major application. It has taken some work to keep it updated with DPI and styles, since it was long ago abandoned, but still works well. Delphi has out of the box docking support, though not as robust or configurable.

[Brandon Staggs 285]

On 6/12/2023 at 2:03 AM, Lars Fosdal said:

Also - what if MS decides to yank out MDI completely? It is, after all, deprecated.

I couldn't find anything in their documentation suggesting it is deprecated. Can you point me to that? Here's what I did find:

 

https://learn.microsoft.com/en-us/windows/win32/winmsg/multiple-document-interface

 

Quote

[Many new and intermediate users find it difficult to learn to use MDI applications. Therefore, you should consider other models for your user interface. However, you can use MDI for applications which do not easily fit into an existing model.]

 

Edited June 13, 2023 by Brandon Staggs

[mvanrijnen 123]

Yes on the last dutch Delphi event from EMB (via Bransten) this was said to. 
 

Also they said that EMB is busy with an update so existing MDI apps will still run & function correctly.

(i think they gonna implement the parts which MS dropped).

see also":

 

 

Edited June 13, 2023 by mvanrijnen

[A.M. Hoornweg 144]

On 6/8/2023 at 12:46 PM, David Heffernan said:

Imagine not being able to make a 64 bit IDE

A 64-bit process can only load 64-bit designtime packages, so it would be a huge breaking change.  Having said that, the very fact that designtime packages are loaded into the IDE process itself is also its Achilles heel. Errors in a package can bring down the IDE. It would be nice if that were no longer the case.

[A.M. Hoornweg 144]

On 6/12/2023 at 8:47 AM, David Heffernan said:

What's the way to replicate MDI like behaviour in VCL today? 

What I would love to see is fully detachable tabs, like in modern browsers.

 

[dummzeuch 1517]

1 minute ago, A.M. Hoornweg said:

Having said that, the very fact that designtime packages are loaded into the IDE process itself is also its Achilles heel. Errors in a package can bring down the IDE. It would be nice if that were no longer the case.

That's not restricted to the Delphi IDE and packages though. Basically any DLL loaded into a process can do the same to that process.

(I'm not sure about dotNET in that respect though.)

[Brandon Staggs 285]

2 minutes ago, A.M. Hoornweg said:

A 64-bit process can only load 64-bit designtime packages, so it would be a huge breaking change.  Having said that, the very fact that designtime packages are loaded into the IDE process itself is also its Achilles heel. Errors in a package can bring down the IDE. It would be nice if that were no longer the case.

I cannot fathom the paradigm shift that would be. Well, I can fathom it, and I think it would be Delphi 8 all over again for them to introduce such a massive breaking change in concept and code. It would be nice if they could isolate the design-time packages enough to protect the IDE, but removing them from the IDE would eliminate one of Delphi's few core advantages over other systems. Whatever they change it to would also require the participation of everyone making packages, which is not going to happen.