Difference between revisions of "Talk:Wml optimisation"
(suggest advice about premature optimization, profiling, and to use term "inline") |
|||
Line 7: | Line 7: | ||
"Or perhaps, you just want to learn how to write code that not only works, but is also efficient." | "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. | 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. |
Revision as of 12:01, 29 October 2013
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.