Re: [Bug-apl] Performance issue when manipulating arrays

[Elias Mårtenson]

Fair enough, but the problem with the cell allocations is that they alone represent 37% of the run time. The clone calls (of which the cell initialisation is part) is 70%. It's clear that reducing the number of clone calls is key. The way to do that is to make sure that the copy-on-write semantics are stable and working.

Then the is the issue of the reference counter. 26% of the time is spent manipulating that. Perhaps moving to the Böhm collector is something to investigate...

Regards,

Elias

On 25 April 2014 18:36, Juergen Sauermann <address@hidden> wrote:

Hi,

just to mention it, cells are not allocated by their constructor because
for cells "placement new" is always used. The allocation of all ravel cells is
done by the Value constructor.

So the 2.2 billion "allocations" are actually 2.2 billion ravel cell initializations
(without involving memory allocation for each cell).

I will nevertheless look into this; I was earlier thinking of a new FILE_IO function
that returns an entire file.

/// Jürgen

On 04/25/2014 08:01 AM, Elias Mårtenson wrote:

Actually, no. I don't actually do that. I only resize the array one every 1000 lines (configurable). Also, the time is not spent there.

As I mentioned, I ran it under Callgrind, and the time spent allocating arrays is actually minimal. What does take time is the 2.2 billion cell allocations and the 50 million calls to Value::clone(). Most of these calls clone a value that that is immediately discarded afterwards.

The solution is to avoid cloning of values that are not stored (that's the core of the "temp" idea). Right now the temp system is only used in some very specific cases, but once that can be used for Value::clone() is when we'll see the big performance boosts.

Regards,

Elias