[http://sourceforge.net/p/ufoai/bugs/1971 Item 1971] imported from sourceforge.net tracker on 2013-01-28 19:14:56

for my windows compiled ufoai (msys setup) battlescape freezes for some minutes - I think only pathfinding execution is done in this time.

freeze occurs on any soldier change or any action. Compiling with suse linux does not freeze the game.
If you need other infos, please ask.
===== Comments Ported from Sourceforge =====

====== wilminator (2009-01-01 22:31:07) ======

Is this just the client, or are you using both the server and the client?
====== rudolfowood (2009-01-02 12:55:19) ======

this is during single-player game. I also experience this during skirmish game. Even if I move a soldier for more than one unit at once (e.g. walk 4 units forward) it seems to calculate moveable places after every step.
How is server/client usage defined? I thought also during singleplayer there is a "server" unit and my client as one of the participants.
====== aduke1 (2009-01-02 23:52:04) ======

Discomfirmed.
Using rev 21362 on Win XP, compiled with std C::B, on a *really* old machine, single player mode, switching between actors does NOT lag here.

====== rudolfowood (2009-01-03 10:56:14) ======

duke: please note that I don't use C::B but "default" make process like described here: http://ufoai.ninex.info/wiki/index.php/Talk:MinGW

I know that for CodeBlocks all compile rules are defined independant from default make - I will check whether it also is ok if I compile via C::B. But this would only mean that there is an error in "default" make process that does not occur on (every) *nix
====== rudolfowood (2009-01-03 11:46:47) ======

I can confirm that it does not happen if I compile with CodeBlocks... so it must be some compiler flag that is not used with codeblocks.
====== aduke1 (2009-01-03 23:42:35) ======

1. What was the last time you were able to compile an exe that did not lag ?
Have you tried to diff the revisions of the makefile @SVN since then ? Maybe someone (accidently ?) changed the compiler flags...

2. Are you sure it only lags with pathfinding/switching actors ?? What about map compile, game startup, load map ?
I have looked at the pathfinding code once or twice and can't remember anything specific that I would immediately associate with compiler flags. Plain C IIRC.

3. A blind shot: If it really is restricted to pathfinding, look for the -funsigned flag and toy with it...
====== rudolfowood (2009-01-05 18:30:00) ======

I think it never worked since new pathfinding was implemented. The only change in makefile flags that I remember and that could influence this was changing from -ansi to -std=c99 (to enable round functions for mingw).

I don't know how I should notice it on parsing/map compile. I noticed that e.g. configure runs much faster on Linux than on windows, but this could be related to msys/mingw emulating some parts of linux (?)

what is the -funsigned flag? I don't know much about compiler flags
====== rudolfowood (2009-01-10 15:46:23) ======

that -funsigned-bitfields/-fsigned-bitfields did not influence anything. I also found that there are more differences between the two make commands, e.g. -D__GNUWIN32__, -pipe, -O0 -fno-inline - but changing/adding any of these also had no influence.

I found another difference: for game.dll and ufo.exe Codeblocks uses mingw32-g++ instead of gcc, which is used on eclipse. But this also did not reveal any influence. I'll do further checks on that.
====== rudolfowood (2009-01-28 18:40:22) ======

I found the suspect, it is nothing with compile:

it slows down massivly because of setting developer to 1, first suspect there is printing very much info into debug logfiles. I think without printing to file this is not a so big problem, I'll check that.
====== rudolfowood (2009-02-14 19:05:42) ======

It is not printing to the logfiles, I could verify. cvar logfile is used to control this, even if I switch file logging off it needs much time. So the inperformant part must be the console logging.
====== tlh2000 (2009-11-09 07:16:56) ======

io is never cheap - but it should not block the game. is this still an issue with current trunk? any research done on this part?
====== tlh2000 (2010-01-06 19:18:51) ======

no further feedback - set to pending
====== rudolfowood (2010-01-06 21:18:45) ======

sorry for late response. As nothing in the logging code has changed, this is still valid. I checked with an almost up-to-date version (27797).

I just checked the generated logfile, for one single Grid_MoveCalc on af_main (skirmish) 181k lines of Grid_MoveMark are logged into the file. So just for that one single calculation (for one soldier) 11 MB of logfile will be generated.

That massive amount must cause a slowdown to stop the game. As we don't have asynchronous logging, this is all done sequential and so it blocks.

Some options:
a) disable that Grid_MoveMark output even if developer is set to 1 (so log it only if requested via developer DEBUG_PATHING, exclude from DEBUG_ALL)
b) decouple logging (e.g. Com_vPrintf or Com_DPrintf does not do logging but only adding it to a queue. have a second process that takes message objects from that queue to do the logging as needed)
c) evaluate why a full grid_moveCalc is done just for reselecting a soldier - as long as nothing changes, no calculation should be needed (calculate the grid once per round for every soldier and update only if some event causes the calculation to be false)

I assigned it to you mattn as I think this is not really related to only pathfinding.
====== aduke1 (2010-01-06 22:04:00) ======

I'd vote for option a), because I assume that's just a few keystrokes and will completely solve the prob. Also only a few devs can actually interpret that output ;)

And I can explain c):
There is just one pathing table for all actors. Some 3MB. And every move of an actor would potentially invalidate the tables for the others. Not to mention kills, func_breakables,...
====== tlh2000 (2010-01-26 07:09:23) ======

please do a) then.
====== aduke1 (2010-02-01 01:55:35) ======

Did a) in r28355.
====== sf-robot (2010-02-15 02:20:20) ======

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).