Array List object?

Gan via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Mon Jan 26 23:18:22 PST 2015


On Tuesday, 27 January 2015 at 06:16:03 UTC, H. S. Teoh wrote:
> On Tue, Jan 27, 2015 at 06:02:38AM +0000, Gan via 
> Digitalmars-d-learn wrote:
>> On Tuesday, 27 January 2015 at 06:00:50 UTC, Gan wrote:
>> >On Tuesday, 27 January 2015 at 05:32:09 UTC, Gan wrote:
>> >>Hey I'm using normal arrays for my project:
>> >>//Declaring the array
>> >>SBTile[] tiles;
>> >>
>> >>//Initializing the array
>> >>tiles = new SBTile[](0);
>> >>
>> >>//Clearing the array
>> >>tiles = [];
>> >>
>> >>//Removing a tile at index i from the array
>> >>tiles.remove(i);
>> >>
>> >>//Adding a tile to the array
>> >>tiles ~= tile;
>> >>
>> >>But I think I'm doing something very wrong because my list 
>> >>of tiles
>> >>is growing larger and larger. Am I misusing the array or is 
>> >>there a
>> >>better way of doing those array list functions?
>> >
>> >Found my problem. When you call remove, you need to set it.
>> >
>> >tiles = tiles.remove(i);
>> >
>> >Though isn't it incredibly inefficient to continually have it
>> >re-create the arrays for adding and removing? I'm asking 
>> >cause I'm
>> >not very knowledgable on this subject.
>> 
>> On a side note, my program's ram usage is increasing very 
>> rapidly. All
>> I'm doing to adding and removing objects from an array.
>
> The answers to your question can be found here:
>
> 	http://dlang.org/d-array-article.html
>
> In short, D "arrays" are actually not arrays directly, but 
> slices of
> arrays (i.e., pointer and length pairs to a segment of memory 
> managed by
> the GC).  Therefore, assigning the return value of .remove back 
> to tiles
> is extremely efficient, because all you're doing is updating 
> the .ptr
> and .length fields of tiles. There is no copying of array 
> elements at
> all (except what's already being done in .remove).
>
> However, the problem comes when you call .remove immediately 
> followed by
> ~=. Because the runtime doesn't know whether you have made 
> other slices
> of the same array in the meantime, it doesn't know whether you 
> wish to
> retain the original array elements, so to be safe, whenever the 
> array
> length shrinks it assumes that the next time you append 
> something new,
> it should reallocate. Thus, every time ~= follows .remove, the 
> array
> will be reallocated, which is extremely slow. The solution is 
> to tell
> the runtime that yes, you do wish to overwrite whatever may 
> have been
> there in GC memory before when you append:
>
> 	tiles = tiles.remove(i);
> 	assumeSafeAppend(tiles); // <--- this is the secret
> 	tiles ~= tile;		// now this won't reallocate everytime
>
> Note that append to the array will still reallocate 
> occasionally (e.g.,
> when there is no more space in the currently allocated GC 
> block, and the
> array needs to be moved to a new memory location where a bigger 
> block
> can be allocated). But it should perform a lot better than 
> reallocating
> every single time you append.
>
>
> T

Thanks! My project use to hover at 80mb ram usage, now it hovers 
at 35mb ram usage. Nevermind. It just climbed up to 65mb

Okay now I'm very confused. When I have my program fully hidden 
behind another window, my ram usage goes up without going down. 
Which my program is partly visible it goes up a few mb then 
returns to the past amount of mb.

Is this a bug?


More information about the Digitalmars-d-learn mailing list