[Trigger] Compiler efficiency?

[Thalassicus]

I'm not really sure if this fits in this forum, but since it's about the interface's compiler I guess it sort of applies.

I've been curious about just what kind of efficiency operations the WC3 compiler does for the final map script (regardless of how it's arrived at, interface-generated or manually coded). I haven't ever had the time to look into the details of how much of maps are compiled vs interpreted; is most of it interpreted?

If a lot of a map is compiled, are things like duplicate instantiations of an object combined (like MS's VC++ compiler does)?

For example, if there are two calls to taking the point that is the center of a region (I'm guessing it creates a new instance of the point class for this purpose, hence all the talk over the years about leaks) does it refer all future calls back to the same instantiated object in memory, or create a new, identical instance of the point class for each individual call? I'm guessing it's the latter, or people wouldn't worry about memory handling so much (after all, quantity of memory used is usually a low concern nowadays unless you're dealing with integrated systems).

I still do all the destroy-instance-of-object operations to be on the safe side, but I sometimes wonder just what the exact tradeoffs are of that, vs the time needed to run the destructors (and hence the memory access operations associated with them, which are rather time consuming as far as most operations go if I remember my computer architecture correctly).

MS's compiler for visual studio is rather remarkable (regardless of any other questionable points as a company you might have of them) at optimizing the final assembly product when you churn something out in release mode... you wouldn't expect a compiler for custom maps in WC3 to be that professional of course, but I still wonder at times just how much efficiency handling, if at all, is done, if there's a reference to specifically how the compiler operates at a lower level somewhere.

 

[PurplePoot]

Jass (and GUI compiles to it) is 100% interpreted. The WE makes absolutely no optimizations, though Vexorian's Map Optimizer makes a good deal.

For example, if there are two calls to taking the point that is the center of a region (I'm guessing it creates a new instance of the point class for this purpose, hence all the talk over the years about leaks) does it refer all future calls back to the same instantiated object in memory, or create a new, identical instance of the point class for each individual call? I'm guessing it's the latter, or people wouldn't worry about memory handling so much (after all, quantity of memory used is usually a low concern nowadays unless you're dealing with integrated systems).

Two identical instances.

I still do all the destroy-instance-of-object operations to be on the safe side, but I sometimes wonder just what the exact tradeoffs are of that, vs the time needed to run the destructors (and hence the memory access operations associated with them, which are rather time consuming as far as most operations go if I remember my computer architecture correctly).

Leaks can cause all sorts of nasty problems, and the destructors generally run faster than you'd care to notice. Also, in Jass, you can mostly get around using those sort of temporary objects regularly anyways (For example, Locations are replaced with individual x and y coordinates).

MS's compiler for visual studio is rather remarkable (regardless of any other questionable points as a company you might have of them) at optimizing the final assembly product when you churn something out in release mode... you wouldn't expect a compiler for custom maps in WC3 to be that professional of course, but I still wonder at times just how much efficiency handling, if at all, is done, if there's a reference to specifically how the compiler operates at a lower level somewhere.

Again, none whatsoever.

 

[Thalassicus]

Thanks for the information, that's mostly what I thought, although it's surprising to learn there's not any optimization at all. And it was puzzling it states 'compiler' errors when saving a map... if it actually does no compilation? Or they just use that word for the processing it into final format...

I use vexorian's applet and take care of major object destruction anyways, since people recommended it six years back, but was curious. One of these days I should probably sit down and learn all the ins and outs of the details of how things work, but eventually you just get weary of the time involved when learning new languages for work on a constant basis (why, oh why do companies all love to use different inhouse versions) plus in recreational use, the python implementation for 3d apps, python for Civilization, linden labs script... lua for wow... there's just not enough time in the world sadly.

Well, I'm rambling; thanks again for the confirmation.

 

[PurplePoot]

Thanks for the information, that's mostly what I thought, although it's surprising to learn there's not any optimization at all. And it was puzzling it states 'compiler' errors when saving a map... if it actually does no compilation? Or they just use that word for the processing it into final format...

It should be called parsing errors, I know. If it's compiled, then it's done while the map is loading, 100%, although I doubt it is due to just how slow some things can be (like wrappers).

In fact, if you save a map which won't "compile", you can test this, because it actually saves properly (albeit the whining) - if you try to run it in Wc3, it will fail to run due to the errors, rather than just... not saving properly.