Merge lp:~widelands-dev/widelands/bug-1786613-10s-return-skipped into lp:widelands

Proposed by Toni Förster
Status: Superseded
Proposed branch: lp:~widelands-dev/widelands/bug-1786613-10s-return-skipped
Merge into: lp:widelands
Diff against target: 12 lines (+1/-1)
1 file modified
src/logic/map_objects/tribes/productionsite.cc (+1/-1)
To merge this branch: bzr merge lp:~widelands-dev/widelands/bug-1786613-10s-return-skipped
Reviewer Review Type Date Requested Status
hessenfarmer Needs Fixing
Review via email: mp+352967@code.launchpad.net

This proposal has been superseded by a proposal from 2018-08-13.

Commit message

reduce waiting time to 10ms for skipped programs

Description of the change

That "penalty" is reduced to 10ms. Which means there is no measurable effect. After 1000 produced wares it would be 10 seconds. For a ware that would be produced constantly every 60 seconds it would take 16.6 in-game hours to result in a loss of 1 product due to the time penalty. Currently this happens very 6 minutes.

I couldn't see any slowdowns or higher CPU usage. My test scenario:

The Nil map, 8 AIs, 2 Teams with all 4 tribes assigned to each team.

My System:

MacBook 7,1
Intel Core2Duo@2.4GHz
16GB Ram
macOS 10.13.6

To post a comment you must log in.
Revision history for this message
bunnybot (widelandsofficial) wrote :

Continuous integration builds have changed state:

Travis build 3782. State: failed. Details: https://travis-ci.org/widelands/widelands/builds/415390227.
Appveyor build 3581. State: success. Details: https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1786613_10s_return_skipped-3581.

Revision history for this message
hessenfarmer (stephan-lutz) wrote :

Ok I tested this with different timings.
My machine is a Core 2 Duo T7500 @ 2,2 Ghz with 4 GB RAM.
My setup was
map: the nile
8 AI players 2 of each tribe
Let the game run for 4:50 hours
saved and loaded with every config.

results were:
original timing: around 30% cpu usage in task manager, peaks up to 45%
10 ms timing: around 33% with more and higher peaks up to 60%
100 ms timing: around 32% less peaks than 10s up to 50%
500 ms timing: around 30 to 31 % peaks up to 50% but not much frequent.

So I would propose to have a value of 500 to 1000ms as compromise to ensure minimal effect on performance.

review: Needs Fixing

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/logic/map_objects/tribes/productionsite.cc'
2--- src/logic/map_objects/tribes/productionsite.cc 2018-06-19 08:52:49 +0000
3+++ src/logic/map_objects/tribes/productionsite.cc 2018-08-13 09:53:54 +0000
4@@ -899,7 +899,7 @@
5 SkippedPrograms::const_iterator i = skipped_programs_.find(program_name);
6 if (i != skipped_programs_.end()) {
7 uint32_t const gametime = game.get_gametime();
8- uint32_t const earliest_allowed_start_time = i->second + 10000;
9+ uint32_t const earliest_allowed_start_time = i->second + 10;
10 if (gametime + tdelta < earliest_allowed_start_time)
11 tdelta = earliest_allowed_start_time - gametime;
12 }

Subscribers

People subscribed via source and target branches

to status/vote changes: