ExecuteFunc?

05-01-2006, 03:36 PM	#1
Thunder_Eye	can I use variables in the call ExecuteFunc() ? like: JASS: function hahayou takes nothing returns nothing endfunction function ThisisMe takes nothing returns nothing local string g = "hahayou" call ExecuteFunc(g) endfunction

05-01-2006, 03:37 PM	#2
Blade.dk	Yes.

05-01-2006, 07:29 PM	#3
The)TideHunter(	Kinda off topic, but i dont know if this is true, but wouldent this leak? JASS: function DoSomething takes nothing returns nothing endfunction function DoSomethingElse takes nothing returns nothing call ExecuteFunc("DoSomething") endfunction cause iv heard strings leak, so couldent they leak like this?

05-01-2006, 07:34 PM	#4
Captain Griffen	Strings leak, but only once, and they aren't really significant. So that might leak the first time it runs, but only once.

05-02-2006, 02:28 PM	#5
blu_da_noob	And there is absolutely nothing you can do about it, so don't bother.

05-02-2006, 03:42 PM

karukef

It is just wrong to say that strings leak.

Strings are allocated and stays allocated to improve performance, both letting multiple identical strings share memory and to avoid reallocating memory when the same string is created over and over again.

So in order to give jassers a bit less to worry about, let's all agree that strings doesn't leak and give up the confusing and technically incorrect "strings leak, but only once"-idiom.

The only advice that should ever be giving about strings and memory is if someone posts code that creates LITERALLY a million different non-equal strings, because that would consume a noticable amount of memory, but no-one does that.

05-02-2006, 04:07 PM	#7
Vuen	Yup, I agree.

05-02-2006, 06:50 PM	#8
PipeDream	I believe that's the reason the game will lag up if you don't fix the local handle hostage bug. Attached var systems start to allocate enormous quantities of strings. If you never need to use a string again, then it is as far as I'm concerned a leak.

05-02-2006, 07:18 PM

karukef

A leak is a technical term used for computer programming when you allocate memory but looses your references to it without telling the underlying operating system that this memory is unused.

Warcraft III intentionally keeps all allocated strings in memory because it makes the game run faster.

Although, how on earth do we know that Warcraft III never de-allocates strings anyway?? People keep saying it, but where does this come from?

05-02-2006, 08:47 PM

#10

Anitarf

Quote:

Originally Posted by PipeDream

I believe that's the reason the game will lag up if you don't fix the local handle hostage bug. Attached var systems start to allocate enormous quantities of strings.

I think that the strings are the smallest of your problems here, as the increasing handle stack takes up a bit of memory itself. In any event, as long as you free handle indexes properly, they'll get recycled, so Attached var systems will be reusing a finite ammount of unique strings, and all will be well.

05-02-2006, 08:50 PM

#11

The)TideHunter(

Yea, good point, theres rumors of all sorts of things like this, but has anybody actually ever completly read the wc3 program that makes what we see work?
Or, the dll's which is just really the program...

EDIT: reading over this topic, i have another question, would this still "leak" like other strings?

JASS:

function DoSomething takes nothing returns nothing
endfunction

function DoSomethingElse takes nothing returns nothing
    local string SomeString = "Hey"
    call ExecuteFunc(SomeString)
    set SomeString = ""
endfunction

05-02-2006, 09:03 PM	#12
iNfraNe	Besides crashing the game that wouldnt help fixing it either no.

05-02-2006, 09:30 PM

#13

PipeDream

We know warcraft doesn't deallocate strings from simple observation. Try running I2S(loop counter) in a loop, executefunc'd to avoid thread crash. Time it with respect to n for several n and draw your own conclusions about this thing that "makes the game run faster". You are welcome to any semantic definition you wish for leak, however, you will have a hard time convincing me that cache that has become deprecated and is never deallocated is not a leak.

Thanks Anitarf, that is what I meant to say- Attached var systems may cause problems only if you don't take care of your handles. I believe that it is the strings that are at fault because, for example, DotA gets away with not nulling while using no attachments. It might be informative to test this directly.

I do not believe the significant factor is the quantity of memory as we have gigabytes to spare. I suspect it is the number of strings. Perhaps the string lookups are done by a tree or a hash table which doesn't scale well.

Tide, people have disassembled game.dll, however nobody has messed with handles on that level yet.

05-03-2006, 10:04 PM

#14

PitzerMike

Well, I actually agree with karukef that the term 'leak' isn't exactly correct here.
Warcaft doesn't lose the reference to those strings so technically it's not a "true" leak.

But of course in reality it has exactly the same effect as a leak, namely that it keeps memory allocated that wouldn't be required any more.

So, well, there are good arguments for both points of view. And although I'm not quite happy with it I'll keep calling them string leaks. Afterall "local handle vars" also have nothing to do with local variables, but nonetheless everyone knows what is meant. I guess it's the same here.

05-04-2006, 10:02 AM	#15
Azazel_	It is similiar to the accounting principle of substance over form. I feel it is okay to determine it as a leak because we do not know how often the strings are being used, and this may vary between maps.