On 3/18/15 2:50 PM, Jim Graham wrote:
On 3/18/15 9:17 AM, Laurent Bourgès wrote:
-------- Here are some "things to consider later" ---------
I just realized the main case where we want to deal with cleaning
out dirty arrays and it would be the crossings accumulation arrays.
It seems to me that those are special cases and so we should
concentrate the cleaning code on those explicitly and not have a
global "lets clean all arrays everywhere" setting.
Agreed.
Let's clarify my approach in marlin: it uses mainly reused arrays (int,
byte, float) => no allocation (GC overhead).
To achieve the best performance, it only clears dirty parts ie used ones
(see the many used mark fields).
Dirty arrays are named "dirty" to indicate that these arrays are used in
a "unsafe" manner ie never zero-filled (always junk). It means the code
must be good enough to always set values and get those that have be set.
Perhaps a naming convention for the variable so that we can spot code
that might rely on cleared data being used on an array that isn't
necessarily cleared then?
Thinking more about this - actually all arrays are (potentially) used in
a dirty manner. Some arrays naturally wouldn't care if the data is
dirty because they are filled from the start and only access the part
that is filled. Others like the coverage accumulation arrays may be
more randomly accessed and so having a predefined start state is
important to them.
So, all arrays would qualify as "dirty" as per your description unless
I'm missing something...?
...jim
