The non-intrusive ad-hoc borrowing scheme…

Paulo Pinto pjmlp at
Fri Nov 22 17:54:53 UTC 2019

On Friday, 22 November 2019 at 16:09:51 UTC, Ola Fosheim Gr wrote:
> On Friday, 22 November 2019 at 15:32:14 UTC, Nick Treleaven 
> wrote:
>> On Wednesday, 20 November 2019 at 06:40:50 UTC, Ola Fosheim 
>> Grøstad wrote:
>>> But maybe it could be configured in a more granular manner 
>>> than on/off.
>> Do you have any ideas on that?
> There are so many options... but if set aside "debug-only 
> ref-counting" then this could be an possible "performance 
> philosophy":
> I thought about something yesterday regarding bounds checks. I 
> think it would be nice if one could state a code section should 
> be @high_performance and then get warnings everywhere safety 
> checks had survived all the optimization passes. Then one would 
> have to mark those bounds checks as "necessary" to get suppress 
> the warning. So that you basically can write safe code that is 
> performant and focus time and energy where it matters.
> If one had ARC optimization like Swift, then maybe something 
> similar could be done for reference counting. In a 
> @high_performance section one would get warnings if the 
> refcount is changed and would have to do explict "borrow 
> statements" to suppress the warnings. Then one could later 
> figure out a way to move those out of performance sensitive 
> code (like loops).
You mean the optimization that gets slammed by state of the art 
tracing GC implementations?

If one cares about performance there are only two paths, linear 
and affine type systems with their complexity for typical every 
day coding, or tracing GCs.

Reference counting GC are just the easy way to get automatic 
memory management, and when one adds enough machinery to make 
them compete with tracing GC in performance, they end up being a 
tracing GC algorithm in disguise.

More information about the Digitalmars-d mailing list