|
From: | John W. Eaton |
Subject: | Re: move constructors |
Date: | Wed, 14 Aug 2019 14:21:58 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
On 8/14/19 1:05 PM, Rik wrote:
This jibes with my sense from the profiling that we are doing a lot of unnecessary creation/destruction of objects. *IF* heavyweight constructors are a problem, then calling them less frequently by using move constructors and move assignment operators would definitely help. However, that is still a hypothesis. Is there a relatively simple way to test this short of re-writing a bunch of classes? One option might be to place a counter in the constructor, assignment operator, and destructor routines for octave_value. I should also say that I tried implementing a move constructor after OctConf2018 and I didn't see any improvement. But, I also could have screwed it up and I didn't spend a long time on it.
Yeah, see the attached simplified version of our Array class. There are a few cases that seem (to me, at least, with my limited understanding) like it should be possible for the compiler to figure out that it can call move constructor or the move assignment operator but it doesn't. But AFAICT, it is following the rules. OTOH, in some cases, the compiler may completely remove calls to the copy constructor or assignment operator even when move constructors are not explicitly defined. This happens for me regardless of the optimization level (using GCC 8.3).
If we see a large penalty for using atomic reference counting, then we must be performing many operations where we increment and decrement the count. Are we doing many of those operations unnecessarily? If so, and given what I see with the example class, I'm wondering why more of these operations are not eliminated. Can we easily find where they are happening? At least that would be a start to understanding what should be done.
Did you post code for your experiments with move constructors and move assignment operators? I don't see it in the archive of the maintainers list, but I may not be searching for the right thing.
jwe
move.cc
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |