winXP 1.1.4 slow as hell

[Darth Fool]

Premature optimization is when code is optimized without knowing whether it is a performance bottleneck or not. Obviously there are performance issues in 1.1.4, so premature optimization is not the issue.

No. premature optimization is optimizing before it is the right time to optimize. If you are optimizing code before you have it working and this optimization will result in more complicated code that will be harder to debug, then that is premature. There are other examples, this is merely meant to demonstrate that your definition is inadequate.

When performance issues appear, they should be dealt with immediately, otherwise you will have to go back and rewrite who knows how much code, which might prove effectively impossible.

No. read this slowly if you have to in order to understand what we are saying. Development releases are for DEVELOPMENT. The developers are not going to put performance as the most important value during the development cycle. For Stable releases, performance issues are a high priority. For development releases they may or may not be depending on the circumstances of that particular release. Taking working code and finding where to optimize is much easier than trying to get buggy optimized code to work.

As for the slow down, yeah I see it on my overpowered machine and it clearly is not acceptable for the long haul. If you wish to contribute, try identifying what in the code causes the slow down to occur. Merely pretending that you are important by spouting off what others must do for you without any compensation is a waste of bits.

[ivanovic]

Since there are such massive speed problems we just came to a decission on how to fix this in our irc channel. It is simple and we should have had this idea before:
We will completely rewrite the game. This time we won't use C++ since it obviously is too slow for wesnoth. We want to get the best optimisation possible so we will directly write machine code aka assembler. Since this is not such a trival task expect the next Wesnoth release in nothing less than six months to one year, we will need our time.
If you do not hear anything from a dev anymore that may be due to heavy work on rewriting wesnoth. And don't start to ask something like "Daddy, is it already completed? When will the assembler version be ready? Oh Daddy, I want it now...". We will as Devs hope to accomplish this task in less than one year, but it will take it's time. Until this has happend you should go on testing 1.1.4...

[Prometheus]

When I say deal with performance issues immediately, I mean before adding new features, not before debugging.

And I am not asking anyone to do anything for me. If anything, I am asking people NOT to do things. Specifically, do not add new features before performance issues are solved.

[Sapient]

So, before any Linux developer checks in any code, they should run a benchmark analysis on Windows XP? Seems unlikely.

And, as for setting other people's priorities, it doesn't work very well here. Sorry, Prometheus, you have a valid point but you are not being realistic. As I said, the developers are working on these performance issues, and personally, I thank them for giving it their attention.

[Anyar]

Since there are such massive speed problems we just came to a decission on how to fix this in our irc channel. It is simple and we should have had this idea before:
We will completely rewrite the game. This time we won't use C++ since it obviously is too slow for wesnoth. We want to get the best optimisation possible so we will directly write machine code aka assembler. Since this is not such a trival task expect the next Wesnoth release in nothing less than six months to one year, we will need our time.
If you do not hear anything from a dev anymore that may be due to heavy work on rewriting wesnoth. And don't start to ask something like "Daddy, is it already completed? When will the assembler version be ready? Oh Daddy, I want it now...". We will as Devs hope to accomplish this task in less than one year, but it will take it's time. Until this has happend you should go on testing 1.1.4...

Are you serious?

[scott]

Since there are such massive speed problems we just came to a decission on how to fix this in our irc channel. It is simple and we should have had this idea before:
We will completely rewrite the game. This time we won't use C++ since it obviously is too slow for wesnoth. We want to get the best optimisation possible so we will directly write machine code aka assembler. Since this is not such a trival task expect the next Wesnoth release in nothing less than six months to one year, we will need our time.
If you do not hear anything from a dev anymore that may be due to heavy work on rewriting wesnoth. And don't start to ask something like "Daddy, is it already completed? When will the assembler version be ready? Oh Daddy, I want it now...". We will as Devs hope to accomplish this task in less than one year, but it will take it's time. Until this has happend you should go on testing 1.1.4...

Are you serious?

No, it wouldn't be cross-platform. Think of all the complaining if they dropped Windows versions altogether.

[Anyar]

Are you serious?

No, it wouldn't be cross-platform. Think of all the complaining if they dropped Windows versions altogether.

Phew... I wasn't sure whether or not that was for real. Devs should be forbidden from using sarcasm around the general population.

[ILikeProgramming]

Since there are such massive speed problems we just came to a decission on how to fix this in our irc channel. It is simple and we should have had this idea before:
We will completely rewrite the game. This time we won't use C++ since it obviously is too slow for wesnoth. We want to get the best optimisation possible so we will directly write machine code aka assembler. Since this is not such a trival task expect the next Wesnoth release in nothing less than six months to one year, we will need our time.
If you do not hear anything from a dev anymore that may be due to heavy work on rewriting wesnoth. And don't start to ask something like "Daddy, is it already completed? When will the assembler version be ready? Oh Daddy, I want it now...". We will as Devs hope to accomplish this task in less than one year, but it will take it's time. Until this has happend you should go on testing 1.1.4...

Are you sure this won't result in problems due to different operating systems?

[Sapient]

Are you sure this won't result in problems due to different operating systems?

Right, he forgot to put that in a [sarcasm][/sarcasm] tag

[torangan]

Phew... I wasn't sure whether or not that was for real. Devs should be forbidden from using sarcasm around the general population.

Users should be forbidden to make demanding or impolite requests.

[zookeeper]

Phew... I wasn't sure whether or not that was for real. Devs should be forbidden from using sarcasm around the general population.

Users should be forbidden to make demanding or impolite requests.

So, to sum it up into something that would be very beneficial to apply to many users on this forum, both dev and user: people should be forbidden to behave like asses.

[Darth Fool]

When I say deal with performance issues immediately, I mean before adding new features, not before debugging.

And I am not asking anyone to do anything for me. If anything, I am asking people NOT to do things. Specifically, do not add new features before performance issues are solved.

There's the rub. You seem to think that developers are experts in all part of the code and for all OS. This is generally false. Developers are generally experts in whatever features that they have added or modified. They also don't generally add features when they notice that there is a performance hit on whichever OS and computer they are working on. They also generally react quickly to slow downs that are obvious enough that they are quickly identified by others when they update their version of the code shortly after the feature is added. Thus performance hits that make it into the repository are usually the result of interactions between features committed by different developers. In order to track these down generally requires that someone with a system where the slow down is noticable takes the time to do a binary search on the revisions to figure out where there specific slow down becomes noticable (hopefully it occurs noticably in a small range of commits and not as a result of several small incremental performance hits). To add complexity to the situation, sometime slowdowns occur as a result of interactions between the code and the configuration files and so only occurs when certain WML tags are active.

So, with all that, why would a developer stop his work on his feature set to hunt down slow downs probably caused by some other features that he knows nothing about? Answer, he won't during the normal development cycle. When a slow down can be isolated to code that is in his area of expertise, he likely will attack it. Also when preparing for a STABLE release, there will be a greater effort to identify where performance hits are coming from. It would be great if we had a developer devoted to tracking the game performance to identify what commits resulted in slow-downs across a multitude of platforms, but this is not a very interesting job and requires multiple OSs to work on, so instead it is generally left to the ad-hoc searches for particular problems when they are noticed. If you are interested in spending time identifying the sources of performance hits, then please do. Pointing out that there is a slow down can be helpful. Announcing that others must drop everything and hunt for it is counter-productive. If on the otherhand, you wish to pay me or one of the other developers who are currently donating our free-time to work on wesnoth full-time, then we might listen to such a request. Until then recognize that if performance is a priority for YOU, then YOU need to do something about it, not expect others to.

[bruno]

We will completely rewrite the game. This time we won't use C++ since it obviously is too slow for wesnoth. We want to get the best optimisation possible so we will directly write machine code aka assembler. Since this is not such a trival task expect the next Wesnoth release in nothing less than six months to one year, we will need our time.

Do you think we can use macros to generate code on separate processor types using one code base or will that slow things down too much.
What processors do you think are worth supporting?
We will probably need to write custom video card drivers as well.
I think this is likely to take more than a year.

[ivanovic]

I'd say we should in general support plain i686 compatible CPUs plus G4 compatible CPUs. This should be enough for most users. maybe we might even need two years but since it is better to have a very performant release for everyone than only adding one or two new features most users will understand this. i Think using macros for porting would not be this good since we could end in having the same bottlenecks we have now. Rewriting the graohic cards drivers might be a really good idea. Maybe this way we could optimise the drivers for complete rewrites of the screen...
So overall we will need two branches, one for i686, one for G4 (ppc compatible). Though we will really have to limit the supported graphic cards due to incompatible specs.



So the simple question is:
Arte users willing to wait for such a highly optimised version that will only work on <50% of the available hardware or are you willing to wait for a stable version that might be working nicely?
Users having speed problems could also compile theirself with heavy optimisations for their CPU. We can't deliver such a build since only some users could use it.
The best thing would be if those having speed problems would give some more details like the exact situations when the speed goes down. Also testing various revisions in the svn and telling where the speed did drop will be really helpfull. So instead of only complaining and wanting "the devs" to do something, try to help the devs. If you only claim to get changes nothing will change. So better try to help us a little and speed might improve. Taking our time in discussions that do not make any sense won't help anyone.

[JW]

I just want to thank you guys again for giving me the medium of Wesnoth to creatively express the Era of Myths. I haven't perceived any slowdown on my Windows 1.1.4 version which pleases me a lot.

Keep on doin' what you're doin.