Jump to content
Ondrej Kelle

Unified Memory Management - Coming with 10.4 Beta

Recommended Posts

I used manual memory handling too, so the change should be fine for me.

 

But I hope that there won't be too many strange, unexpected errors, caused by the changed Free/Dispose timing now.

Share this post


Link to post

Unification is good. Going to cause headaches for anybody with ARC only code. Don't think that's going to be an easy migration path.

 

Such a shame that this happened at all, but good for Emba for having the strength to change direction. 

  • Like 5

Share this post


Link to post
Posted (edited)
43 minutes ago, David Heffernan said:

Unification is good. Going to cause headaches for anybody with ARC only code. Don't think that's going to be an easy migration path.

While anything is possible, I don't think there is too much ARC only code around. For anything TComponent based ARC was never working in the first place (you had to use DisposeOf) so most of UI code should work as-is.

 

Since manual memory management is what people are used to, migration path should be relatively easy, although it may be harder to find exact places where object needs releasing. I would follow constructors .Create - usually destruction is somewhere nearby - either in Destroy, or in the same method. Also, on mobile small leaks are not that critical, usually applications are killed anyway before such leaks cause substantial problems, and larger leaks are easily found just by looking at code.  With Instruments and Android Studio you can easily spot problematic parts of  application with large leaks.

 

Not ideal situation... but what is done is done.

Edited by Dalija Prasnikar
  • Like 2

Share this post


Link to post
Posted (edited)

I actually never heeded the warnings my FMX code generated when in ARC mode. I need Windows as well so...good on me, for once. :classic_ninja:

Edited by Sherlock
Fixed a stupid spelling error

Share this post


Link to post

I was not using FMX for serious development, so for me nothing will change at all.
Except, maybe I will give FMX another try. Hopefully FMX will improve faster without ARM. There's a lot to catch either to match VCL counter part or Android Studio! 

 

What I really want to see:

  1. Bug Fixes

  2. RTL Improvement / optimization

  3. Debugger Stability Win32 AND Win64

  4. IDE Quality

  5. Language Server Protocol for Delphi

  6. Language Enhancements: Managed Records 
  7. Unified memory management across all platforms 
  8. VCL High DPI Styles Support 
  9. VCL Per Control Styling
  10. New VCL Components
  11. Updated VCL styles for HighDPI
  12. Windows API Updates

Share this post


Link to post
5 minutes ago, Clément said:

Except, maybe I will give FMX another try. Hopefully FMX will improve faster without ARM. There's a lot to catch either to match VCL counter part or Android Studio! 

I assume you meant "FMX will improve faster without ARC. "

 

But, no, FMX improvements (as in framework improvements) are in no way related to memory management model. The only difference between FMX and VCL code related to memory management is that FMX calls DisposeOf to release FMX components and VCL calls Free. Bottom line, FMX will just run faster on mobile platforms without ARC, but that is it. 

 

Other improvements will come (or not) unrelated to the memory management mode change.

  • Like 3

Share this post


Link to post
21 minutes ago, Dalija Prasnikar said:

I assume you meant "FMX will improve faster without ARC. "

ARC! I need coffee for my memory management

 

  • Haha 3

Share this post


Link to post

We have a maybe ~40k-50k LoC iOS app in FMX for 5+ years and it only ever has had maybe 1 place it specifically needed DisposeOf and/or [weak]. Everything else just uses Free as it supports Windows as well.

  • Like 1

Share this post


Link to post
Posted (edited)

I would like to see in some future version of Delphi:

Edited by Kryvich
  • Like 1

Share this post


Link to post
Guest

Only partially OK... why not ARC or adding Garbage Collector? Manual memory management is pain and only slows you down. I understand that at least ref. counting for interfaces remains, at least this one.

 

They should remove this silly copy/paste of undisclosed getters/setters for properties exposed under interface, and why they require getters/setters in first place there. They should remove that sort of things too.

 

Share this post


Link to post
15 hours ago, Kryvich said:

I would like to see in some future version of Delphi

How is that relevant to the topic?

Share this post


Link to post
12 hours ago, TomDevOps said:

Manual memory management is pain and only slows you down.

You should probably rephrase that "and only slows me down".

 

In my experience laziness always comes at a price. Not bothering to use descriptive identifiers saves a few keystrokes at the price of readability. ARC and GC relieves the developer of having to deal with some of the complexities of resource management, at the price of performance. Etc.

 

I would honestly rather have good performance and full control of what's going on with the resources.

 

 

12 hours ago, TomDevOps said:

They should remove that sort of things too.

Yes. Let's break COM support so we can save some keystrokes.

  • Like 6

Share this post


Link to post
Guest
Posted (edited)
18 hours ago, Anders Melander said:

You should probably rephrase that "and only slows me down".

Not really... I would argue that this applies to anyone 👹

 

18 hours ago, Anders Melander said:

In my experience laziness always comes at a price. Not bothering to use descriptive identifiers saves a few keystrokes at the price of readability. ARC and GC relieves the developer of having to deal with some of the complexities of resource management, at the price of performance. Etc.

 

I would honestly rather have good performance and full control of what's going on with the resources.

...and you will spend much more time 🙂 I do not dismiss performance and stuff, but then use C/C++ 😈 It is rare to use one language for all use cases.

 

Pretty much all mainstream languages have either ARC or Garbage Collector; and neither ARC or GC are perfect, still C# can outperform Delphi, thus in my view, GC is not always a problem.

 

18 hours ago, Anders Melander said:

Yes. Let's break COM support so we can save some keystrokes.

Not necessarily... why not to use pre-processor sort-of-thing to generate stuff like this for compiler? Why we have to make this big bulky header section? The more I write in Swift or C#, the less I like Delphi.

 

But anyway, for dead language with no future, it probably does not matter at all and I guess I should be happy that it happens to be that Delphi is still quite modern so some legacy code, still out there, can be even improved.

Edited by Guest

Share this post


Link to post
16 hours ago, TomDevOps said:

But anyway, for dead language with no future, it probably does not matter at all and I guess I should be happy that it happens to be that Delphi is still quite modern so some legacy code, still out there, can be even improved.

Well luckily this is not a Cobol forum - no wait, even that will not die (german article on 60 years of Cobol: https://www.heise.de/developer/meldung/60-Jahre-COBOL-Die-Sprache-die-nicht-totzukriegen-ist-4518334.html) Then another surely dead language maybe, let's try Fortran ... oops, not dead (https://www.vortech.nl/en/fortran-is-alive/).

TL;DR: Don't make unsustainable claims. 😉

Share this post


Link to post
Guest
46 minutes ago, Sherlock said:

Well luckily this is not a Cobol forum - no wait, even that will not die (german article on 60 years of Cobol: https://www.heise.de/developer/meldung/60-Jahre-COBOL-Die-Sprache-die-nicht-totzukriegen-ist-4518334.html) Then another surely dead language maybe, let's try Fortran ... oops, not dead (https://www.vortech.nl/en/fortran-is-alive/).

TL;DR: Don't make unsustainable claims. 😉

You missed the point, those languages are long dead... there are almost no jobs. This is the bottom line. That is, dead language is not literally dead and you can try to find jobs and write in them, but it will be very hard to do so, so either there are jobs for maintaining legacy system or to support re-writing process; and barely you can find new development - why? Back to square one, there are just few developers on the market. That is the whole point 😉 

 

This is important, show me the actual job list for Delphi in let's say Paris (assume I cannot relocate due to family), do the same for Fortran/Cobol. And how many new development is done in Fortran and Cobol? Almost none. Thus, people will not invest their time into technology in which you cannot find a jobs. This is interlocking problem, I doubt Cobol, Fortran, Delphi, Basic, Modula-2 etc., will ever gain more attraction. That would still a niche technology.

 

TL;DR: the language is dead when there are almost no jobs for it, leaving only few maintaining legacy code jobs.

Share this post


Link to post

Please stay on topic.

Share this post


Link to post

Resurrecting an old thread...

Anybody aware if unified memory management will be in 10.4?

I've kept an eye on Marco's blog and it's not mentioned....

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×