[DISCUSS] Performance Optimisations

[alpha123]

This speeds up asm.js which is a subset of javascript. So it won't generally speed up our code unless we rewrite it. asm.js is pretty different from standard javascript.

Conceivably for releases we could compile regular JS to asm.js. A JS->asm.js compiler doesn't yet exist, but I'm willing to bet one will pop up sooner or later.

That may actually not be that bad of an idea; it could speed up the GUI and maybe some other stuff. Also I think they're planning to make the asm.js -> C++ bridge cheaper, so all our mixed JS/C++ components would have less overhead.

[zoot]

Loading "Punjab 1" on a modern laptop after a fresh boot takes a ridiculously long time for me. 4 minutes and 40 seconds to be exact. Is it this bad on release versions too, or does it only affect development ("SVN") versions where there may be no pre-cached data?

Edited April 9, 2013 by zoot

[idanwin]

??? 4 minutes 40 seconds ???

My laptop has never taken more than 30 seconds to load a map

(although it has taken more than 2 minutes to generate a huuuuuuuge map)

I use SVN, not sure how much difference first after fresh boot makes, I'll test that when I restart my laptop.

[zoot]

After that one first load, subsequent loads only take a few seconds for me too. So there must be some kind of caching going on.

[Lion.Kanzen]

Yeah after first loading takes some time to run normally . In forest deep is the map that give to me most problems. For me that unplayable in any configuration.

[Yggdrasil]

After that one first load, subsequent loads only take a few seconds for me too. So there must be some kind of caching going on.

Most likely the disk cache of the kernel, caching recently used files in RAM. Besides, 0ad caches stuff too (DDS textures,...).

I've made a very simple texture atlas working with compressed DDS files (without decompression). It's just a proof-of-concept. I could clean it up a bit if there's interest. It's probably only really useful if you start to batch things in the renderer. Something to keep in mind for the new renderer.

[zoot]

Most likely the disk cache of the kernel, caching recently used files in RAM. Besides, 0ad caches stuff too (DDS textures,...).

Oh, wow. My disk must either be very slow then, or the engine's IO very inefficient.

[Yggdrasil]

Guess why most commercial games use big package files to store data (besides obscuring it)? It's faster to seek in one big file than open/close many tiny files. Uses less syscalls and locality will be better too (only if you mostly read sequential), if the file isn't fragmented. Then you can also memory-map this file easier to get even more performance.

https://en.wikipedia.org/wiki/Memory-mapped_file

But i don't think you need all that stuff. Loading time is still acceptable.

[fabio]

This is already supported in 0 A.D.. SVN keeps the files but the official releases use a public.zip (with no compression so to be able to compress it more in the installer) file with all the file packaged in it.

[Yggdrasil]

Ah, ok. Then i haven't said a thing...

[tuan kuranes]

- Why Octree ? That's for 3d spatial subdivisions, in 2d, it's quadtree, but that's just a name for sparse hierarchical grid.

So what you need here, is better grid performance and usage (in los, path, culling).

And for that, the key in order to support huge maps and huge agent number, key is to be "hierarchical". For instance:

_grid, etc: http://theory.stanfo...sentations.html

_ hierarchical pathfinding, hpa/hpa+:

http://aigamedev.com...pa-pathfinding/

http://digestingduck...athfinding.html

http://digestingduck...tion-grids.html

Units and formation will also benefits from hierarchical, where group/formation only request one hierarchical path, and the agents are just "following the path" (using very simple steering/swarming algos)

- Performance wise: memory work to do, as there should be no new/alloc/free/delete during main loop, ( Typically CMATRIX3D::operator* appears in profiler hot spots because it allocates a new CMatric3D from the stack each time in its return. correct way is how Cmatrox3d::GetInverse does, which is having a "dest" parameters. ) Data should be located in contigous space in memory, so that cpu cache is optimal. (ie you don't check each bouding box against clipplanes individually, but all bounding box against clipplanes)

Read all data oriented design papers available. (http://dice.se/publi...riented-design/)

Edited April 28, 2013 by tuan kuranes

[idanwin]

After that one first load, subsequent loads only take a few seconds for me too. So there must be some kind of caching going on.

Oh, yes, sorry. It takes a while until all textures appear correctly on the first run. With this included it does take some time.

Edited April 28, 2013 by idanwin

[zoot]

Thanks for testing. Must be the expected behavior then.

[jP_wanN]

Today, I added a little patch to trac that provides some byte-sized performance improvements (http://trac.wildfire...com/ticket/2127). Should I add it to "Ongoing improvements" on the GamePerformance Wiki page? I am not sure if it is meant as a general overview or as a Todo-list for things not done yet.

Edited September 12, 2013 by jP_wanN

[Yves]

Today, I added a little patch to trac that provides some byte-sized performance improvements (http://trac.wildfire...com/ticket/2127). Should I add it to "Ongoing improvements" on the GamePerformance Wiki page? I am not sure if it is meant as a general overview or as a Todo-list for things not done yet.

Thanks for the patch, I will have a look at it this weekend or next week.

Why do you think it improves performance? There are some style improvements but I don't see changes that could improve performance.

Please check this one again. I think the expression in ENSURE will only be evaluated in debug mode, but it also has to wait for the semaphore in release mode.

@@ -558,9 +555,7 @@

double CDebuggingServer::AquireBreakPointAccess(std::list<CBreakPoint>** breakPoints)
{
-	int ret;
-	ret = SDL_SemWait(m_BreakPointsSem);
-	ENSURE(0 == ret);
+	ENSURE(SDL_SemWait(m_BreakPointsSem) == 0);
	 (*breakPoints) = &m_BreakPoints;
	 m_BreakPointsLockID = timer_Time();
	 return m_BreakPointsLockID;

EDIT: I've tested it. The expression is also evaluated in release mode.

Somehow I assumed it wouldn't because that's how most implementaitons of ASSERT work.

[alpha123]

Please check this one again. I think the expression in ENSURE will only be evaluated in debug mode, but it also has to wait for the semaphore in release mode.

EDIT: I've tested it. The expression is also evaluated in release mode.

Somehow I assumed it wouldn't because that's how most implementaitons of ASSERT work.

According to lib/debug.h it runs in both, although the comments are rather ambiguous about its intended usage. Thanks for testing though, as I wasn't totally sure.

We actually have both ENSURE and ASSERT. lib/debug.h is very clear that ASSERT only runs in debug builds, although not so clear about ENSURE. Otherwise I think their usages are identical.

[RedFox]

1. ENSURE is a simple macro that is always used, regardless of Release/Debug.
   
2. ASSERT uses ENSURE.
   
3. ASSERT is undef'd in Release builds.