Just a request to the developers of the fpc with a faint hope

[beria]

I am currently programming a telemetry server for industrial equipment. As part of the logic, arrays of different binary data blocks are constantly, in all threads and in large quantities, created and destroyed... In the beginning I had a very nice and compact version through classes and dynamic arrays. In terms of performance it was terrible... Now, with great difficulty, I rewrote its basic block only on writes and GetMem/FreeMem and it runs as much as 35% faster according to first tests.... Yes, I was very surprised...
Then I found out that it's all my fault - invisible zeroing of dynamic arrays and classes content, which I didn't need. For arrays I even found it in the fpc code, disabled it, recompiled the whole fpc and got +20% performance at once...
Maybe you should think about making a compilation key that removes this zeroing?
And if you need mandatory initialization, that's a good thing, maybe it's better to do it like in pascalABC and anonymous classes? There it looks like var p := new class(Name, Age);
 

[marcov]

Smartest is to simply pool classes rather than allocating/freeing them.

The initialization probably won't change due to Delphi compatibility, and there are no plans to abandon Pascal and adapt Java syntax either. (even if Pascal.ABC.NET does)

[beria]

The initialization probably won't change due to Delphi compatibility,

fpc is already incompatible with Delphi without compatibility key, and even not completely with it, as my import experience tells me... and this is quite normal and fine with me, especially since I have never been oriented to Delphi in the first place. And in so many places the logic of work and even the syntax of FPC changes depending on the conditional compilation keys...
It's just that everything I wrote about is quite solvable, just by abandoning the direct way of solving it, based on basic language constructs and requiring programming your own low-level procedures... So, in my opinion, of course, I'm not arguing with anyone and I don't think my opinion is that important, but it's an artificial creation of problems, in order to solve them heroically, instead of dealing with more high-level problems...

Ps: by the way such a thing can be as one of the possible keys of optimization...

[Martin_fr]

For classes you can override TObject.NewInstance

1) This allows you to have memory pools for each class, taking the memory from the pool, and thereby avoiding the memory manager and potential memory fragmentation.
Yet that will still zero the memory in TObject.InitInstance.


2) Or of course taking an already existing instance from a pool.
If you override TObject.FreeInstance and instead of freeing the class, add it to a pool for later re-use.
That would mean you could still use .Create, .Destroy or .Free etc as normal.

I don't however know if you can (and also will be able in future FCP releases) safely call  "CleanupInstance" to free all the managed types (if any).

3)
>>>                START OF "Here be dragons".      <<<
If you overrode TObject.NewInstance you could of course you could skip the call to InitInstance (and thereby avoid zeroing the mem).
But you would have to do the work yourself. And that may need to be updated each time you change FPC version.  There are reasons for the initialization.
You don't get it 100% right, and bad things will happen.

For arrays, I don't have any idea... Just alloc the mem, and use index on pointers: varPointerToMyType[4]

The downside, you can't compile debug versions with range checking for that => which means you loose some options of testing your code.

[Arioch]

>

And if you need mandatory initialization, ... do it like in pascalABC and anonymous classes? There it looks like var p := new class(Name, Age);

not better

if you have 100 fields, you would end up initializing them in random order and by random data widths.
That hardly would be faster than a single run of FillChar(ptr, total size, 0)

and you can not avoid initializations, because you would have managed, ARC-driven types (long strings, interfaces, dyn-arrays, annonymous functions (interfaces too), etc). and every field of that type MUST be zeroed out.

But if you want, you have it - "advanced records" - they do run Initialize(...) and it traverses RTTI to precisel zero only ARC-fields and leave garbage in others. Is it much better? Then use advanced records not classes.

Now, there still is the 3rd options, the Tubo-Pascal style objects, rather than classes. They are told to be faster. But simpler. I consider TObject.AfterConstruction a great hook, provifing great flexibility, but it makes construction code flow much more convoluted, thus slow. Still, go into KOL forum ,and they stick with objects not classes, if i got that right. Cause they want a smallest possible footprint and they do not need rich funcitonality.

Those KOL maniacs... I remember i made a 2KB DLL with them - only to find that Windows can never laod such a small thing :-)

[PascalDragon]

Maybe you should think about making a compilation key that removes this zeroing?

As Martin_fr wrote, for classes you can already control that by reimplementing NewInstance. For dynamic arrays: no, we don't want to add the possibility for that.