ClearList is very convenient.

BlitzMax Forums/BlitzMax Programming/ClearList is very convenient.

sswift

(Posted 2006) [#1]

That's all I wanted to say!

big10p

(Posted 2006) [#2]

There's ClearList in B3D, now? Wow, I'll have to check it out... or have you got the wrong forum!? :P

sswift

(Posted 2006) [#3]

I guess I must have got the wrong forum. :-)

OJay	(Posted 2006) [#4]

well,

Delete Each myType

is very convenient too ;P

Ice9	(Posted 2006) [#5]

if one of your fields points to an entity that must be freed then I guess you are on your own

N	(Posted 2006) [#6]

Or, better yet: yourList.Clear( )

ziggy

(Posted 2006) [#7]

yourlist = new TList

N	(Posted 2006) [#8]

ziggy: That requires that you allocate a new TList, which is obviously not going to be as fast as setting the current TList's head successor and predecessor to itself.

ziggy

(Posted 2006) [#9]

If your using your 'cleared' list, this is the fastest way to send all of it's contents to the GC and leave it ready to recive new contents. Take in consideration that alocating an empty list is absolutely ultra fast. In my opinion, manipulating the header of a list is not a good practicle, it works ok, but it's not much elegant, but you know, that's only my opinion.

:D

Happy coding!

N	(Posted 2006) [#10]

Try this, ziggy.

SuperStrict

Local l:TList
Local t:Int

t = Millisecs( )
For Local i:Int = 0 To 80000
	l = New TList
Next
t = Millisecs( ) - t
Print t

t = Millisecs( )
For Local i:Int = 0 To 80000 ' Added another zero just so the results are clearer
	l.Clear( )
Next
t = Millisecs( ) - t
Print t

To elaborate, creating a new list takes more time because it's making more calls to functions.

For one, it has to allocate the memory from the GC pool if needed, then it has to call the Object.New method, then the TList.New method which has to create the new head TLink which has to repeat the process of allocating the memory, calling Object.New, and then calling TLink.New.

Whereas TList.Clear is, quite simply, changing the value of some variables.

N	(Posted 2006) [#11]

Here's another example of why just creating a new TList is bad.

SuperStrict

Type MyType ' 8 bytes not counting the header and super-class
    Field foo:Int
    Field bar:Int
End Type

Local k:Int = GCMemAlloced( )

Local l:TList = New TList
Print GCMemAlloced( )-k
For Local i:Int = 0 To 511
    l.AddLast( New MyType )
Next
Print GCMemAlloced( )-k

l = New TList

For Local i:Int = 0 To 256
    GCCollect( )
Next
Print GCMemAlloced( )-k

Now replace l = New TList with l.Clear( ) and the memory leak disappears.

Insert audible gasp here.

Dreamora

(Posted 2006) [#12]

There is no memory leak.
If BM would act like modern GC it would not reduce the pools size unless the RAM is filled as there is no real need for it ... reduzing the pool size just wastes performance ...

N	(Posted 2006) [#13]

Unfortunately, it is a leak, Dreamora. You can't reuse the memory wasted by the still-in-use list.

Dreamora

(Posted 2006) [#14]

The strange thing is: That should not happen.
The delete method of TList does a clear as well.

This damned delete bugs (ie GC is still incapable of securely call the delete method on any drop!!) just let many internal data structures look bugged!

dmaz	(Posted 2006) [#15]

Noel, does the memory not return on program completion?

N	(Posted 2006) [#16]

It does, but that's irrelevant. The thing we need to be concerned about is memory use and speed during runtime. Creating new lists instead of clearing is not only slower but also can introduce memory leaks. Depending on the size of the objects, the memory leak could be very, very large or 8 bytes minimum.

ziggy

(Posted 2006) [#17]

Well, usualy memory is not free when it's not used. BM can leave some 'overhead' memory when objects are deleted, becouse freeing and alocating memory is not much fast. Most of programing languages act like this. this not freed but unused memory is used to alocate new objects when necesary, while there is available memory on the computer. I can't ensure that BlitzMax does it this way, but it is the way it shoud work.

Anyway, there's no way to know exactly how GC manages memory unless you analize the source code of BlitzMax... and it's not an easy task to do

N	(Posted 2006) [#18]

Anyway, there's no way to know exactly how GC manages memory unless you analize the source code of BlitzMax... and it's not an easy task to do

You're telling this to one of the people who did it.

Dreamora

(Posted 2006) [#19]

Then you surely could fix the "delete call not guaranteed on deleting list from pool" error thats causing the mentioned problem ... Delete calls clear() but the delete does not seem to be called ... although there is no obvious reason for it. TLinks don't have a reference to their list so this should theoretically be deleted for sure and thus delete called.

N	(Posted 2006) [#20]

I'm not doing BRL's job. If you know this is in fact a bug, report it.