Watch, Follow, &
Connect with Us

Please visit our new home
community.embarcadero.com.


Welcome, Guest
Guest Settings
Help

Thread: Optimizing ARC



Permlink Replies: 46 - Last Post: Mar 10, 2018 3:57 AM Last Post By: Rudy Velthuis (... Threads: [ Previous | Next ]
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 30, 2018 12:45 AM
Hi,

I have been doing blog series on optimizing ARC code:

Optimizing ARC with unsafe references
https://dalijap.blogspot.com/2018/01/optimizing-arc-with-unsafe-references.html

Optimizing ARC the hard way
https://dalijap.blogspot.com/2018/01/optimizing-arc-hard-way.html

While main concern is optimizing code on ARC compilers, same principles
apply to reference counted objects used through interfaces on classic
desktop compilers.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Alexandre Machado

Posts: 1,754
Registered: 8/10/13
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 30, 2018 4:29 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:
Hi,

I have been doing blog series on optimizing ARC code:

Optimizing ARC with unsafe references
https://dalijap.blogspot.com/2018/01/optimizing-arc-with-unsafe-references.html

Optimizing ARC the hard way
https://dalijap.blogspot.com/2018/01/optimizing-arc-hard-way.html

While main concern is optimizing code on ARC compilers, same principles
apply to reference counted objects used through interfaces on classic
desktop compilers.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/

Thanks for that.

This partially explains why all Delphi/Linux applications I've seen to date are much slower than the same compiled using the old and good Win32 Delphi compiler.
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 31, 2018 10:40 AM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre Machado wrote:

This partially explains why all Delphi/Linux applications I've seen to date are much slower than the same compiled using the old and good Win32 Delphi compiler.

Yes, existing code is not exactly ARC friendly.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 5, 2018 2:40 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

My thoughts on that:

Optimizing ARC the hard way?
http://rvelthuis.blogspot.de/2018/02/optimizing-arc-hard-way.html

--
Rudy Velthuis http://www.rvelthuis.de

"What I am against is quotas. I am against hard quotas, quotas
they basically delineate based upon whatever. However they
delineate, quotas, I think, vulcanize society. So I don't know
how that fits into what everybody else is saying, their relative
positions, but that's my position." -- George W. Bush

Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 6, 2018 4:51 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB, MVP) wrote:
Dalija Prasnikar wrote:

My thoughts on that:

Optimizing ARC the hard way?
http://rvelthuis.blogspot.de/2018/02/optimizing-arc-hard-way.html


On one hand I would say that changing compiler behavior would be
acceptable solution. In fact, I was also considering something similar
as one of the possible solutions.

My major concern in this case is that such solution can potentially introduce
long term mess in order to satisfy short term goals. I am not sure. For
one thing I would not like to jump on that idea without thinking about
it more thoroughly.

Specifically, if such solution is applied it would permanently remove ability
to trigger reference counting on passed objects. Adding another compiler
switch could solve that, but do we really need another one?

Also if reference counting is disabled for objects it would only be logical that
it gets disabled for interfaces too. However, that would bring another possible
compatibility issues.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 7, 2018 12:40 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

Rudy Velthuis (TeamB, MVP) wrote:
Dalija Prasnikar wrote:

My thoughts on that:

Optimizing ARC the hard way?
http://rvelthuis.blogspot.de/2018/02/optimizing-arc-hard-way.html


On one hand I would say that changing compiler behavior would be
acceptable solution. In fact, I was also considering something
similar as one of the possible solutions.

My major concern in this case is that such solution can potentially
introduce long term mess in order to satisfy short term goals.

The only "mess" I can see is that some code that does assign to the
parameter won't compile anymore, and would have to be modified. That
won't be much code, AFAICT.

I don't know what happens if you do

takeConstObject(TMyClass.Create);

Similar code using interfaces can fail:

takeConstInterface(TImplementingClass.Create);

because the refcount is still 0 and that can cause premature
destruction if inside the procedure, the refcount is incremented and
then decremented again. But if you do:

takeConstInterface(TImplementingClass as IMyInterface);

then all is well. I thought ARC classes are created with a refcount of
1 and not with 0, so this should be safe:

takeConstObject(TMyClass.Create);

Am I wrong?

--
Rudy Velthuis http://www.rvelthuis.de

"The exact contrary of what is generally believed is often the
truth."
-- Jean de la Bruyère
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 7, 2018 2:03 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB, MVP) wrote:

I don't know what happens if you do

takeConstObject(TMyClass.Create);

Similar code using interfaces can fail:

takeConstInterface(TImplementingClass.Create);

because the refcount is still 0 and that can cause premature
destruction if inside the procedure, the refcount is incremented and
then decremented again.

ARC reference counting behaves the same whether the item is an object
or an interface. So the same issue exists for objects as with
interfaces when the parameter is const.

I thought ARC classes are created with a refcount of
1 and not with 0, so this should be safe:

takeConstObject(TMyClass.Create);

Am I wrong?

Just like with TInterfacedObject, the initial reference count of
TObject is forced to 1 during construction, and is then decremented
after construction.

In a non-ARC system, TInterfacedObject sets its reference count to 1 in
an overriden NewInstance() method, and decrements its reference count
in an overriden AfterConstruction() method. TObject is not reference
counted.

In an ARC system, TObject sets its reference count to 1 in
TObject.NewInstance(), and the compiler decrements the reference count
after TObject.AfterConstruction() exits (in
System._AfterConstruction()). TInterfacedObject inherits its reference
count handling from TObject, it does not implement its own handling as
it does on a non-ARC system.

--
Remy Lebeau (TeamB)
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 7, 2018 3:14 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Rudy Velthuis (TeamB, MVP) wrote:

I don't know what happens if you do

takeConstObject(TMyClass.Create);

Similar code using interfaces can fail:

takeConstInterface(TImplementingClass.Create);

because the refcount is still 0 and that can cause premature
destruction if inside the procedure, the refcount is incremented and
then decremented again.

ARC reference counting behaves the same whether the item is an object
or an interface. So the same issue exists for objects as with
interfaces when the parameter is const.

Actually, that is not true. It is a bit more complicated on the ARC side.

If parameter is declared as object reference then inline creation of object
instance will work properly in ARC. If parameter is const, instance will enter procedure
with reference count of 1 and if parameter is not const then reference count will be 2.

But, if parameter is declared as interface, then inline creation will be as broken as
it is on non-ARC compiler. With const param object will enter procedure having
reference count 0, and if parameter is not const then it will be 1.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 7, 2018 3:49 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

If parameter is declared as object reference then inline creation of
object instance will work properly in ARC. If parameter is const,
instance will enter procedure with reference count of 1 and if
parameter is not const then reference count will be 2.

Given the RTL code I looked at, I don't see how that can be true,
unless the compiler recognizes the inline creation and assigns the
object to a hidden local variable (which is a fix people have been
asked for inline interface creation for years!). Otherwise, I would
expect the reference count to be 0 for const and 1 for non-const.

But, if parameter is declared as interface, then inline creation will
be as broken as it is on non-ARC compiler.

Since TInterfacedObject uses the TObject reference counting mechanism
on ARC, and an inline TInterfacedObject creation starts with a
reference count of 0 (thus causing the broken behavior), that would
imply that an inline TObject creation should also start with a
reference count of 0, not 1. So, the compiler increments the reference
count of TObject but not TInterfacedObject (a TObject descendant)?
That makes no sense.

--
Remy Lebeau (TeamB)
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 8, 2018 1:53 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Dalija Prasnikar wrote:

If parameter is declared as object reference then inline creation of
object instance will work properly in ARC. If parameter is const,
instance will enter procedure with reference count of 1 and if
parameter is not const then reference count will be 2.

Given the RTL code I looked at, I don't see how that can be true,
unless the compiler recognizes the inline creation and assigns the
object to a hidden local variable (which is a fix people have been
asked for inline interface creation for years!). Otherwise, I would
expect the reference count to be 0 for const and 1 for non-const.

Other things you said are true. On all compilers reference counted
instance starts with reference count 0. It is the first assignment to
strong reference (implicit or explicit) that initializes reference count to 1
and instance can begin its life with proper count.

When it comes to object references ARC compiler creates hidden
reference that allows proper counting of inline constructed instance
even if parameter is const.

But, if parameter is declared as interface, then inline creation will
be as broken as it is on non-ARC compiler.

Since TInterfacedObject uses the TObject reference counting mechanism
on ARC, and an inline TInterfacedObject creation starts with a
reference count of 0 (thus causing the broken behavior), that would
imply that an inline TObject creation should also start with a
reference count of 0, not 1. So, the compiler increments the reference
count of TObject but not TInterfacedObject (a TObject descendant)?
That makes no sense.

It is not about object class, but parameter type. Inline construction of
TInterfacedObject on ARC compiler if parameter is declared as TObject
or TInterfacedObject will behave properly.

Reference counting is broken only if parameter is declared as const interface.

In other words, ARC compiler has proper behavior implemented when it comes
to inline creation and passing object references - but that code must have been
newly written.

Broken behavior from non-ARC compiler with inline creation and passing interface
references was just "copied" from old compiler to new one.

Simply, interfaces are reference counted on classic compiler and this bug slipped
under the radar because it looked like that part of behavior didn't have to be updated
for new ARC compiler.

I hope this makes some sense :)

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 8, 2018 10:28 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

It is not about object class, but parameter type. Inline construction
of TInterfacedObject on ARC compiler if parameter is declared as
TObject or TInterfacedObject will behave properly.

Reference counting is broken only if parameter is declared as const
interface.

Well, that is backwards then. The compiler should be looking at what
is actually being created, not what it is being assigned to afterwards.
Inline creation creates a temp object, regardless of how that temp is
used. So the temp should be tracked appropriately. If the temp
happens to be passed to a const interface parameter, it will have a
valid reference count.

Simply, interfaces are reference counted on classic compiler and this
bug slipped under the radar

I doubt that. Embarcadero devs are well aware of the problem of inline
creation of interface parameters, they have acknowledged it before,
they just won't fix it.

--
Remy Lebeau (TeamB)
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 8, 2018 11:50 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Dalija Prasnikar wrote:

It is not about object class, but parameter type. Inline construction
of TInterfacedObject on ARC compiler if parameter is declared as
TObject or TInterfacedObject will behave properly.

Reference counting is broken only if parameter is declared as const
interface.

Well, that is backwards then. The compiler should be looking at what
is actually being created, not what it is being assigned to afterwards.
Inline creation creates a temp object, regardless of how that temp is
used. So the temp should be tracked appropriately. If the temp
happens to be passed to a const interface parameter, it will have a
valid reference count.

Absolutely. I have been saying that all along.

Actually, not exactly... but similar... you cannot just look at what has been created
without broader context, since reference counting mechanism constructs objects
with "invalid" reference count of 0 and the first assignment - broader context
is responsible for triggering reference counting mechanism (or not in the case
of desktop compiler - where assignment to object reference does not trigger
ref counting)

Following that logic - you have to look at the procedure parameter. It matters
whether it is object or interface reference - but only on desktop compiler.
What you don't need to care about - for the purpose of instance construction
is how it is passed - as const or not - that is a separate step.

It is two step process merged into one liner for simplicity.

One of my comments on the issue

"And finally, inline creation of object instance is logically two step operation merged
in single one in order to simplify code and remove need for declaring additional variable.
First step is object creation and its assignment to initial strong reference (implicit or explicit)
and second step is passing it as parameter where you don't want to trigger reference count.
If this process is followed step by step creating implicit strong reference that triggers reference
count is logically completely separated from the next step that says passing this reference
as parameter will not trigger reference counting mechanism."

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

Simply, interfaces are reference counted on classic compiler and this
bug slipped under the radar

I doubt that. Embarcadero devs are well aware of the problem of inline
creation of interface parameters, they have acknowledged it before,
they just won't fix it.

I am saying that while they were making full ARC implementation they forgot
about that issue. I have hard time imagining they would leave it broken on
ARC compiler on purpose.

But that does not really matter anyway. Point is there is a bug that needs to be fixed.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 8, 2018 1:34 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

Absolutely. I have been saying that all along.

Actually, not exactly... but similar... you cannot just look at what
has been created without broader context

The context should't matter to how the object is created, but the
fact that it does is a mistake on the compiler's part.

When a object is created, its reference count is 0. When the object is
assigned to a variable, whether that be explicitly in code, or
implicitly by the compiler for a temp object, then the reference count
would be 1. Done. What the context does what that variable afterwards
should be irrelevant to the object's lifetime management.

But that is not how the compiler actually works, but that is how it
should work.

--
Remy Lebeau (TeamB)
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 8, 2018 1:58 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Dalija Prasnikar wrote:

Absolutely. I have been saying that all along.

Actually, not exactly... but similar... you cannot just look at what
has been created without broader context

The context should't matter to how the object is created, but the
fact that it does is a mistake on the compiler's part.

Well, yes...

When a object is created, its reference count is 0. When the object is
assigned to a variable, whether that be explicitly in code, or
implicitly by the compiler for a temp object, then the reference count
would be 1. Done. What the context does what that variable afterwards
should be irrelevant to the object's lifetime management.

But that is not how the compiler actually works, but that is how it
should work.

Agreed.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 7, 2018 4:21 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

If parameter is declared as object reference then inline creation of
object instance will work properly in ARC. If parameter is const,
instance will enter procedure with reference count of 1 and if
parameter is not const then reference count will be 2.

But, if parameter is declared as interface, then inline creation will
be as broken as it is on non-ARC compiler.

That may be, but the fact that an inline created ARC object has a
refcount of 1 means that the cmpiler could really be made to treat
every ARC object reference as const without any big problems.

The problems with interraces ae not solved by that, but that is not the
topic of this thread (and your and my blog posts) anyway.

I would love to look at the generated code for ARC, but ATM, my Mac has
problems and can only be started in safe mode (and hence Parallels with
the Mac/ioS/Linux Delphi setup won't start).

--
Rudy Velthuis http://www.rvelthuis.de

"I dream that someday the United States will be on the side of
the peasants in some civil war. I dream that we will be the
ones who will help the poor overthrow the rich, who will talk
about land reform and education and health facilities for
everyone, and that when the Red Cross or Amnesty International
comes to count the bodies and take the testimony of women
raped, that our side won't be the heavies."
-- Richard Cohen
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 8, 2018 1:58 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB, MVP) wrote:
Dalija Prasnikar wrote:

If parameter is declared as object reference then inline creation of
object instance will work properly in ARC. If parameter is const,
instance will enter procedure with reference count of 1 and if
parameter is not const then reference count will be 2.

But, if parameter is declared as interface, then inline creation will
be as broken as it is on non-ARC compiler.

That may be, but the fact that an inline created ARC object has a
refcount of 1 means that the cmpiler could really be made to treat
every ARC object reference as const without any big problems.

Of course. And Barry Kelly confirmed this is the bug in compiler and
that all that is needed is hidden reference that would allow proper
reference counting.

It is not question of being hard to fix (though some say every fix is a hard one ;)
but the willingness to actually fix this issue.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 7, 2018 3:53 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:

ARC reference counting behaves the same whether the item is an object
or an interface.

Can't be. With interfaces I can do:

TMyClass.Create as IMyInterface

I assume (didn't look yet) there is an unnamed interface ref to which
the interface is assigned.

What would you do with

TMyArcClass.Create

No unnamed interface ref. So there is a difference already.

--
Rudy Velthuis http://www.rvelthuis.de

"The secret of happiness is to admire without desiring."
-- F. H. Bradley
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 8, 2018 1:42 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB, MVP) wrote:
Dalija Prasnikar wrote:

Rudy Velthuis (TeamB, MVP) wrote:
Dalija Prasnikar wrote:

My thoughts on that:

Optimizing ARC the hard way?
http://rvelthuis.blogspot.de/2018/02/optimizing-arc-hard-way.html


On one hand I would say that changing compiler behavior would be
acceptable solution. In fact, I was also considering something
similar as one of the possible solutions.

My major concern in this case is that such solution can potentially
introduce long term mess in order to satisfy short term goals.

The only "mess" I can see is that some code that does assign to the
parameter won't compile anymore, and would have to be modified. That
won't be much code, AFAICT.

I would only change reference counting trigger, not the rest of the value
semantics.

Problem is that while with value semantic you don't exactly get copy of
the object, you do get strong reference to it. I know that if you need it
you can always grab another from within the procedure, but that complicates
such code a bit.

What I am not sure is how realistic is above scenario (beyond fixing broken
interface counting). Until I can say for sure it is not, I would not jump to
changing pass by value behavior as solution.

It seems the best at the moment, but I have my reservations.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 7, 2018 5:08 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
what I would like to know is
using Linux and FMXlinux
I use code like
try
create something
do something with that
finally
free what I created
end

no memory leak in my code on OSX
but that same code base compiled for Linux, I am getting a memory leak
(I have not been able to track it down)
I suspect its something to do with that Linux compiles with ARC (and OSX does not)
?
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 7, 2018 8:45 PM   in response to: Brian Hamilton ... in response to: Brian Hamilton ...
Brian Hamilton Hamilton wrote:

what I would like to know is
using Linux and FMXlinux
I use code like

try
create something
do something with that
finally
free what I created
end

ARC or not, you should be creating the "something" before entering the
'try' block, not creating it inside of the 'try' block:

create something
try
  do something with that
finally
  free what I created
end


no memory leak in my code on OSX

No leak, but you are running the risk of crashing your code if you try
to free "something" that has not been constructed properly. That is
why you shouldn't enter the 'try' block until after the construction is
finished first.

but that same code base compiled for Linux, I am getting a memory leak
(I have not been able to track it down)

How do you know it is leaking memory?

Since you haven't shown real code, we can't really help you diagose
the culprit.

The most likely scenario I can think of is that your "do something"
code is creating extra references to "something" that you are not
clearing before freeing "something" (which will simply nil the one
reference being "freed", but not other references).

What is "something"'s RefCount value before you "free" it?

If you need to destroy "something" in memory, even if there are other
references to it, then use DisposeOf() instead of Free(). And consider
using [weak] referencing where appropriate.

--
Remy Lebeau (TeamB)
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 7, 2018 9:50 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...

ARC or not, you should be creating the "something" before entering the
'try' block, not creating it inside of the 'try' block:

i do actually do that...my bad in that example
I could try using desposeof instead of free :)

Edited by: Brian Hamilton Hamilton on Feb 7, 2018 9:51 PM
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 7, 2018 9:54 PM   in response to: Brian Hamilton ... in response to: Brian Hamilton ...
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 8, 2018 11:29 AM   in response to: Brian Hamilton ... in response to: Brian Hamilton ...
what has helped a lot is by setting use zero based strings to false compiler directive
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 8, 2018 6:17 PM   in response to: Brian Hamilton ... in response to: Brian Hamilton ...
Brian Hamilton Hamilton wrote:
what has helped a lot is by setting use zero based strings to false compiler directive

Fighting the compiler all days. This is the sadness of all Delphi users
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 12, 2018 5:20 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Brian Hamilton Hamilton wrote:
what has helped a lot is by setting use zero based strings to false
compiler directive

Fighting the compiler all days. This is the sadness of all Delphi
users

If you are fighting the compiler all day, it is time to find another
one. But fact is that Delphi is a language in which it is very easy to
express your ideas. No fighting required.

If you are constantly fighting the compiler, you may want to read the
Delphi language guide before you continue.

--
Rudy Velthuis http://www.rvelthuis.de

"Tact is the ability to tell a man he has an open mind when he
has a hole in his head." -- Unknown
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 12, 2018 10:11 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
If you are fighting the compiler all day, it is time to find another
one.
Have a look for the response list. The fighting man is not me. Do you understand?

As for me. I have abandon Delphi for a long time on mobile. And many friends around me even abandon Delphi on windows.
Only ARC on windows will be the day i abandon Delphi completely. As you wish.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 13, 2018 4:05 PM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

If you are fighting the compiler all day, it is time to find another
one.

Have a look for the response list. The fighting man is not me. Do
you understand?

No, I don't. Wo else is "fighting the compiler all day"? Some may be
unhappy with some design decisions, or with policy decisions, but that
is not the same as "fighting the compiler all day".

You must be one unhappy puppy.

As for me. I have abandon Delphi for a long time on mobile. And many
friends around me even abandon Delphi on windows.

Yes, such things happen. There will always be flow, both away from and
toward Delphi. <shrug>

--
Rudy Velthuis http://www.rvelthuis.de

Cropp's Law: The amount of work done varies inversely with the
amount of time spent in the office.
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 26, 2018 5:56 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Interesting.

https://quality.embarcadero.com/browse/RSP-19995?filter=-4

It's open state. Haha....
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 27, 2018 9:30 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Interesting.

https://quality.embarcadero.com/browse/RSP-19995?filter=-4

It's open state. Haha....

It was Closed today as "Works as Expected".

--
Remy Lebeau (TeamB)
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 27, 2018 4:47 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
It's open state. Haha....

It was Closed today as "Works as Expected".

There is no serious problem now. _

Edited by: wenjie zhou on Feb 27, 2018 4:48 PM
Jeremy North

Posts: 402
Registered: 9/20/99
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 28, 2018 12:40 PM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:
It's open state. Haha....

It was Closed today as "Works as Expected".

There is no serious problem now. _

Edited by: wenjie zhou on Feb 27, 2018 4:48 PM

Guess you haven't tried using a samsung keyboard with a delphi android app.
Even an embarcadero support case can't get that one fixed properly...
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 28, 2018 4:52 PM   in response to: Jeremy North in response to: Jeremy North
Jeremy North wrote:
wenjie zhou wrote:
It's open state. Haha....

It was Closed today as "Works as Expected".

There is no serious problem now. _

Edited by: wenjie zhou on Feb 27, 2018 4:48 PM

Guess you haven't tried using a samsung keyboard with a delphi android app.
Even an embarcadero support case can't get that one fixed properly...

Yes, you are right. I do not use Delphi on mobile. Although I have always expected Delphi to be one of the very good tools for the mobile platform .
First, they have a lot of energy to develop selfdrawing component on mobile. I'm full of doubts about it. Now, It turns out, it's really wrong. Embarcadero overestimates his ability.
In my opinion, one wrong decision after another . Originally, there was a good development in Delphi2009. From Delphi XE3, it's the beginning of the disaster .
I don't know what happened after the release of XE2 . But I believe XE3 interrupts the process of developing Delphi in the right direction .
Mike Margerum

Posts: 590
Registered: 12/1/99
Re: Optimizing ARC [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2018 8:26 AM   in response to: wenjie zhou in response to: wenjie zhou
Yes, you are right. I do not use Delphi on mobile. Although I have always expected Delphi to be one of the very good tools for the mobile platform .
First, they have a lot of energy to develop selfdrawing component on mobile. I'm full of doubts about it. Now, It turns out, it's really wrong. Embarcadero overestimates his ability.

Rendered controls can be done well and also be performant.

https://flutter.io
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 26, 2018 9:54 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Just now, a graduate has rejected our position. He said "This direction (Delphi) is too cold ".
I don't remember how many times such a thing happened.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 10, 2018 3:15 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Just now, a graduate has rejected our position. He said "This
direction (Delphi) is too cold ". I don't remember how many times
such a thing happened.

He probably meant "too cool". More or less like "I'm too sexy for my
shirt", but vice versa.

--
Rudy Velthuis http://www.rvelthuis.de

"Smith & Wesson - the original point and click interface."
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 10, 2018 3:20 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Just now, a graduate has rejected our position. He said "This
direction (Delphi) is too cold ". I don't remember how many times
such a thing happened.

He probably meant "too cool". More or less like "I'm too sexy for my
shirt", but vice versa.

--
Rudy Velthuis http://www.rvelthuis.de

"Smith & Wesson - the original point and click interface."
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 10, 2018 3:29 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Just now, a graduate has rejected our position. He said "This
direction (Delphi) is too cold ". I don't remember how many times
such a thing happened.

He probably meant "too cool". More or less like "I'm too sexy for my
shirt", but vice versa.

--
Rudy Velthuis http://www.rvelthuis.de

"Smith & Wesson - the original point and click interface."
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 10, 2018 3:34 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Just now, a graduate has rejected our position. He said "This
direction (Delphi) is too cold ". I don't remember how many times
such a thing happened.

He probably meant "too cool". More or less like "I'm too sexy for my
shirt", but vice versa.

--
Rudy Velthuis http://www.rvelthuis.de

"Smith & Wesson - the original point and click interface."
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 10, 2018 3:37 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Just now, a graduate has rejected our position. He said "This
direction (Delphi) is too cold ". I don't remember how many times
such a thing happened.

He probably meant "too cool". More or less like "I'm too sexy for my
shirt", but vice versa.

--
Rudy Velthuis http://www.rvelthuis.de

"Smith & Wesson - the original point and click interface."
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 10, 2018 3:50 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Just now, a graduate has rejected our position. He said "This
direction (Delphi) is too cold ". I don't remember how many times
such a thing happened.

He probably meant "too cool". More or less like "I'm too sexy for my
shirt", but vice versa.

--
Rudy Velthuis http://www.rvelthuis.de

"Smith & Wesson - the original point and click interface."
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 10, 2018 3:51 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Just now, a graduate has rejected our position. He said "This
direction (Delphi) is too cold ". I don't remember how many times
such a thing happened.

He probably meant "too cool". More or less like "I'm too sexy for my
shirt", but vice versa.

--
Rudy Velthuis http://www.rvelthuis.de

"Smith & Wesson - the original point and click interface."
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 10, 2018 3:54 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Just now, a graduate has rejected our position. He said "This
direction (Delphi) is too cold ". I don't remember how many times
such a thing happened.

He probably meant "too cool". More or less like "I'm too sexy for my
shirt", but vice versa.

--
Rudy Velthuis http://www.rvelthuis.de

"Smith & Wesson - the original point and click interface."
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Optimizing ARC [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 10, 2018 3:57 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Just now, a graduate has rejected our position. He said "This
direction (Delphi) is too cold ". I don't remember how many times
such a thing happened.

He probably meant "too cool". More or less like "I'm too sexy for my
shirt", but vice versa.

--
Rudy Velthuis http://www.rvelthuis.de

"Smith & Wesson - the original point and click interface."
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 13, 2018 11:00 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:
Brian Hamilton Hamilton wrote:
what has helped a lot is by setting use zero based strings to false compiler directive

Fighting the compiler all days. This is the sadness of all Delphi users

ah but that challenge
a bit of reading, a bit of googling, and a bit of experimenting..and success
I like the fact I have Linux support with Delphi for FMXLinux and I can use the same code base as the OSX support...brilliant really :)
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 13, 2018 1:05 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:
Hi,

I have been doing blog series on optimizing ARC code:

Optimizing ARC with unsafe references
https://dalijap.blogspot.com/2018/01/optimizing-arc-with-unsafe-references.html

I filed QP report.

Optimize RTL and FMX frameworks for ARC - iterating through collections
https://quality.embarcadero.com/browse/RSP-19924

While we wait for more optimized compiler capable of optimizing on its own,
there is no reason why simpler code optimizations would not find their way
into speed critical code.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Clement Doss

Posts: 76
Registered: 3/26/00
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 14, 2018 10:50 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Hi

I have been doing blog series on optimizing ARC code:
Very nice articles! Thanks.

My main concern would be with multithread.
Most of the projects I'm developing must be thread-safe, and of course, multi-threaded.
Working with STRING in such environment is reference counting error prone. Some extra care is required when copying string between thread or processes and most of the time a PCHAR (or PSTRING) must be use to avoid reference counting issues. I'm forced to avoid ARC with strings that has ARC for a long time and is supposedly more stable than what is coming.

Should I be worried with my class passing between processes?

Clément
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Optimizing ARC
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 15, 2018 4:42 AM   in response to: Clement Doss in response to: Clement Doss
Clement Doss wrote:
Hi

I have been doing blog series on optimizing ARC code:
Very nice articles! Thanks.

My main concern would be with multithread.
Most of the projects I'm developing must be thread-safe, and of course, multi-threaded.
Working with STRING in such environment is reference counting error prone. Some extra care is required when copying string between thread or processes and most of the time a PCHAR (or PSTRING) must be use to avoid reference counting issues. I'm forced to avoid ARC with strings that has ARC for a long time and is supposedly more stable than what is coming.

Should I be worried with my class passing between processes?

Define thread safe ;)

Yes, ARC is threadsafe. If you have issues with ARC and threads
(including strings) then your code is to blame.

As long as thread owns strong reference to the entity (string, object...)
it can safely use it.

If you are having reference counting issues with multithreading that
means your threads either don't have their own strong reference to
that entity or you have failed to deliver that reference in thread safe
manner.

Advantage of ARC is that you can safely use shared objects between
multiple threads and you don't have to worry about when and how you
can destroy that instance. If each thread owns its strong reference it
can use that object reference (this does not cover mutating object content)
and when it is done, it can set that reference to nil without impacting other
threads ability to use that object. When the last thread is finished
object will be released.

On the other hand, manual memory management allows you to create
instance in one thread and pass object pointer to another where it will
be released. That scenario does not work with ARC because if other thread
is not capable of safely obtaining strong reference, when original reference
goes out of scope - other thread will lose the object too.

Without exact code it is hard to say what and how you were doing wrong
if you had issues with strings and reference counting (I believe there are
no reference counting bugs in that area that would make valid code behave
badly) and I am almost 100% sure there are no object reference counting
bugs that would impact multithreading.

Of course, you have to be aware that assigning object references is not
thread safe operation, if you have read/write access across multiple threads
you have to synchronize that reference reading/writing.

I am using reference counted object instances (interfaces) and passing them
between threads via thread safe queue, for years in my Windows code
without a single glitch.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02