UFO:Alien Invasion

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?

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.

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.

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.

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

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...

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.

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

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.

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.

Is this just the client, or are you using both the server and the client?