1.1.2a performance issue.
Moderator: Forum Moderators
Forum rules
Before reporting issues in this section, you must read the following topic:
Before reporting issues in this section, you must read the following topic:
1.1.2a performance issue.
Okay, I admit I'm tired from a long day work, and I'm a little annoyed at how long Wesnoth takes to load/save games.
Since 1.1.1, the time necessary to perform those in/out operations have doubled. It may sound like overkilling, but it genuinely feels that way. I'm usually playing in medium or hard difficulty level, so I have to reload quite often because of losing this or that critical character.
And spending more time during load/save phases instead of actually playing is more than a bit frustrating. I've tried toggling off some options, but it has not changed anything. Music or video modes aren't affecting performances.
For info, I'm running BoW 1.1.2a on a AMD AthlonXP 1.6GHz with 1.5 Gb of DDR, with W2k Pro sp4. It's not the top, but it has endured a full Morrowind with merely 512 Mb of DDR.
Understand me, I do like the improvements of latest version, there are more interesting and/or beautiful features and it's a pleasure playing the game, still (when I'm not tired enough to resent the time issue).
But I would highly recommand to focus the next release on performance. I'm trying to understand what happens during save/load time that costs so dear : as far as I know, it's only text files, and even in Java, flushing a text file the same size (over 1200 Kb) takes less time.
I have noticed that the save files have a full trace of events of the running scenario. I would suggest flushing the incoming data in a temporary file, in asynchronous mode so it does not disturb the course of the game, and when the "next turn" button gets hit, delete old automatic save and rename temporary file into autosave. Such system operations are usually very quick. Now I don't know if the programming language is flexible enough to ensure portability of system instructions...
My apologies if I sound too harsh or too conceited, it's not the intent. I felt like my venting m'frustration here would be like speaking for other players as well.
Since 1.1.1, the time necessary to perform those in/out operations have doubled. It may sound like overkilling, but it genuinely feels that way. I'm usually playing in medium or hard difficulty level, so I have to reload quite often because of losing this or that critical character.
And spending more time during load/save phases instead of actually playing is more than a bit frustrating. I've tried toggling off some options, but it has not changed anything. Music or video modes aren't affecting performances.
For info, I'm running BoW 1.1.2a on a AMD AthlonXP 1.6GHz with 1.5 Gb of DDR, with W2k Pro sp4. It's not the top, but it has endured a full Morrowind with merely 512 Mb of DDR.
Understand me, I do like the improvements of latest version, there are more interesting and/or beautiful features and it's a pleasure playing the game, still (when I'm not tired enough to resent the time issue).
But I would highly recommand to focus the next release on performance. I'm trying to understand what happens during save/load time that costs so dear : as far as I know, it's only text files, and even in Java, flushing a text file the same size (over 1200 Kb) takes less time.
I have noticed that the save files have a full trace of events of the running scenario. I would suggest flushing the incoming data in a temporary file, in asynchronous mode so it does not disturb the course of the game, and when the "next turn" button gets hit, delete old automatic save and rename temporary file into autosave. Such system operations are usually very quick. Now I don't know if the programming language is flexible enough to ensure portability of system instructions...
My apologies if I sound too harsh or too conceited, it's not the intent. I felt like my venting m'frustration here would be like speaking for other players as well.
Hmm...perhaps I should regression-test against Wesnoth 1.1.1 to see if my new macros (for fully deleting arrays and key-value variables) are as superfluous there as in Wesnoth 1.0.2.
They're worth a speed factor of 2 on my unofficial port of Mystery Campaign for 1.1.2a...restoring it to about the speed the original had in Wesnoth 1.0.2.
They're worth a speed factor of 2 on my unofficial port of Mystery Campaign for 1.1.2a...restoring it to about the speed the original had in Wesnoth 1.0.2.
-
- Retired Developer
- Posts: 1086
- Joined: September 16th, 2005, 5:44 am
- Location: Hamburg, Germany
I agree, wesnoth feels (and is) a lot slower at the moment. Please understand though, that this is a development release and we are concentrating on features and bugfixing at the moment. There have been one or two times where we experienced severe performance hits (like factor 5-10 or more) and when that happens we go for improving it. But afar from that it is something you probably will have to wait for until we approach the next stable release .
Smart persons learn out of their mistakes, wise persons learn out of others mistakes!
That answers fairly my concern. I'm rather new to this community and did not know this had happened already. If it is somehow part of the life-cycle of Wesnoth, well, I'll be patient.Yogi Bear wrote:I agree, wesnoth feels (and is) a lot slower at the moment. Please understand though, that this is a development release and we are concentrating on features and bugfixing at the moment. There have been one or two times where we experienced severe performance hits (like factor 5-10 or more) and when that happens we go for improving it. But afar from that it is something you probably will have to wait for until we approach the next stable release .
(And despite what my first post might lead to believe, I know better than complaining about a free, opensource game undergoing what I'd call software "childhood disease". )
-
- Retired Developer
- Posts: 1086
- Joined: September 16th, 2005, 5:44 am
- Location: Hamburg, Germany
No, it is not just you, this functionality is a little bit "unreliable" atm.
The reason lies in the way this is implemented. The client asks the server for replay data and processes it (so actually its not a true skip but a very fast forward mode, ignoring all the animations). The problem is: The client does not know when there is no more data from the server. So if it asks for data and nothing gets send, it assumes that there is nothing more to process and stops. Unfortunately, if the server is busy (running many games for example), the answer might be a little late. If that happens, the "normal" replay mode is activated and it looks as if this function does not work.
I will see how i can enhance this in the next version. Maybe i can introduce some kind of timeout, that makes the client wait longer. Or i get the turn information from the server and make it run up to there.
The reason lies in the way this is implemented. The client asks the server for replay data and processes it (so actually its not a true skip but a very fast forward mode, ignoring all the animations). The problem is: The client does not know when there is no more data from the server. So if it asks for data and nothing gets send, it assumes that there is nothing more to process and stops. Unfortunately, if the server is busy (running many games for example), the answer might be a little late. If that happens, the "normal" replay mode is activated and it looks as if this function does not work.
I will see how i can enhance this in the next version. Maybe i can introduce some kind of timeout, that makes the client wait longer. Or i get the turn information from the server and make it run up to there.
Smart persons learn out of their mistakes, wise persons learn out of others mistakes!
Re: 1.1.2a performance issue.
Deleting all old, unnecessary savegames solved that issue for me on OS X.Nyxl wrote:*snip* annoyed at how long Wesnoth takes to load/save games *snip*
There are only 10 types of people in the world: Those who understand binary, and those who don't ...