Talk:Wml optimisation - Revision history

Xudojnik at 07:03, 12 October 2014

2014-10-12T07:03:29Z

Xudojnik at 07:03, 12 October 2014

2014-10-12T07:03:04Z

Iceiceice at 12:01, 29 October 2013

2013-10-29T12:01:05Z

Iceiceice: suggest advice about premature optimization, profiling, and to use term "inline"

2013-10-29T12:00:33Z

suggest advice about premature optimization, profiling, and to use term "inline"

New page

Thoughts (iceiceice):

So I think you might want to say a few words, (or link to a general explanation of) the programming mantra "premature optimization is the root of all evil". Maybe something like http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize, although I'm not sure its the best.

I'm slightly concerned that some parts of on lines like

"Or perhaps, you just want to learn how to write code that not only works, but is also efficient."

will encourage people to start just employing all optimization techniques throughout their code, which is generally a bad thing.

In case of wml, the mantra would say that even though wml bloat can be a problem, its still best to just write things in the most natural and clear way first and then only start eliminating macros / going to custom events / insert tag syntax after project is mostly done and you have a performance issue. You might also want to mention that people can use things like saving time stamps to profile their code to try to figure out where the slow parts are, or look at a savefile to see what wml their leaning tower of macros is actually creating.

I have never worked on an add-on large enough to require this stuff so what I'm writing above is just boilerplate, but afaik this is part of "best practice" in any programming context.

I think you might also want to include more explanation in the line "macros [b] do not [/b] improve performance!". Maybe add something like "macros are fully expanded inline whenever your scenario is loaded into memory." I guess you do kind of say this but you don't use the word inline anywhere.

@@ Line 17: / Line 17: @@
 --[[User:Xudojnik|Xudojnik]] ([[User talk:Xudojnik|talk]]) 07:03, 12 October 2014 (UTC)
 I think that first example with zombies is not an optimisation.
 First: Even if it is not about zombies and villages. Why do you use custom event if you can just write loop in moveto event?
 Second: One rarely need to spawn a lot of units in one point. In campaigns one usually spawn them in some area or in predefined points. Thats why it is easier to use GENERIC_UNIT macro several times with different coordinates.

← Older revision		Revision as of 07:03, 12 October 2014
Line 14:		Line 14:

	I think you might also want to include more explanation in the line "macros [b] do not [/b] improve performance!". Maybe add something like "macros are fully expanded inline whenever your scenario is loaded into memory." I guess you do kind of say this but you don't use the word inline anywhere.		I think you might also want to include more explanation in the line "macros [b] do not [/b] improve performance!". Maybe add something like "macros are fully expanded inline whenever your scenario is loaded into memory." I guess you do kind of say this but you don't use the word inline anywhere.
		+
		+	--[[User:Xudojnik\|Xudojnik]] ([[User talk:Xudojnik\|talk]]) 07:03, 12 October 2014 (UTC)
		+	I think that first example with zombies is not an optimisation.
		+	First: Even if it is not about zombies and villages. Why do you use custom event if you can just write loop in moveto event?
		+	Second: One rarely need to spawn a lot of units in one point. In campaigns one usually spawn them in some area or in predefined points. Thats why it is easier to use GENERIC_UNIT macro several times with different coordinates.

@@ Line 7: / Line 7: @@
 "Or perhaps, you just want to learn how to write code that not only works, but is also efficient."
-  will encourage people to start just employing all optimization techniques throughout their code, which is generally a bad thing.
+will encourage people to start just employing all optimization techniques throughout their code, which is generally a bad thing.
 In case of wml, the mantra would say that even though wml bloat can be a problem, its still best to just write things in the most natural and clear way first and then only start eliminating macros / going to custom events / insert tag syntax after project is mostly done and you have a performance issue. You might also want to mention that people can use things like saving time stamps to profile their code to try to figure out where the slow parts are, or look at a savefile to see what wml their leaning tower of macros is actually creating.