I've built a couple of 100 prisoner size prisons, and the game runs fine on load, but slows down quite quickly. Exiting and reloading regularly helps to keep things playable, although you have to pick your time, as I've gone in to an instant riot on game load a couple of times now

I politely disagree. I've heard PA has problems taking advantage of extra cores. If only one core is being used effectively, then the above specs are below par.

The two options are to:
1. Upgrade cpu (very cheap oldish AMD cpus are available for next to nothing). I personally run PA on a dual core AMD AM2 5600 and it runs quite well because each core runs at 2.8ghz (roughly 3 times the speed of each of your cores).
2. Wait until the alpha's developed to a stage where it effectively uses multiple cores.

Last edited by paktsardines on Sun Jun 02, 2013 2:02 pm, edited 1 time in total.

I politely disagree. I've heard PA has problems taking advantage of extra cores. If only one core is being used effectively, then the above specs are below par.

The two options are to:1. Upgrade cpu (very cheap oldish AMD cpus are available for next to nothing). I personally run PA on a dual core AMD AM2 5600 and it runs quite well because each core runs at 2.8ghz (roughly 3 times the speed of each of your cores).2. Wait until the alpha's developed to a stage where it effectively uses multiple cores.

I have a sandy bridge i7, 16gb of RAM, and 1 gb of vram, and I'm still getting lag. When I save, and reload, however, the lag disappears. I'm 85% certain it's a memory leak, which is to be expected from an alpha. Hakuna matata. Waiting is the best advice. Also, make bug reports. They cant fix it if you dont report it!

lonewolf40000 wrote:Right now opinions are swaying towards a memory leak.

There's clearly a lot of memory leaking, just open task manager (or your platform's equivalent) and open a large prison in prison architect, you'll see the MBs go up quite rapidly even though nothing gamebreaking is really happening. And this won't stop.

However, there's more going on, since there are also performance issues that crop up even straight away after saving, and long before the system has run out of memory.

I haven't had an issue so far, but I noticed today something that did set it off, that might explain why at certain times the game is unplayable:

I started a new small map (no lag)

I created blueprints using the planning tool (no lag)

I created fencing around the area (no lag)

I created foundations for about 5 large buildings (no lag)

The buildings had materials delivered (lag)

I have an I7-3770K, 16GB of 1600Mhz RAM, and a GTX560 2GB.

Here is my theory:

What started the lag was the appearance on screen of a lot of 'dynamic' objects. Things like walls an floors are not 'dynamic'. They cannot be moved, so they (based on how they are coded) have a smaller memory footprint.

Items like food, people, materials, etc. that can be moved are 'dynamic.' There is some extra information in them that takes up a larger memory footprint. Furthermore, something about the game pays a lot of attention to where these dynamic objects are. So as the deliveries came in, there was then a lot of lag.

As my workmen built out the foundations, and the bricks/steel began to turn into walls/flooring, the lag receded and disappeared. This indicates that 'static' objects take up less memory/processing, and aren't a cause of lag.

On the other hand, large deliveries, lots of 'people,' and a lot of 'interaction' with 'dynamic' objects might cause a large jump in instructions/memory, which might account for the lag in larger populations or upon initial build.

This is just my guess, but based on my (limited) understanding of software programming, if I had to guess, something about 'dynamic' objects take up more memory, and PA is designed (for whatever reason) to spend a lot of processing power knowing what those dynamic objects are doing, and as of such, when you have a certain number of them on screen, it begins to lag badly, as the engine is now executing too many instructions monitoring those dynamic objects.

This would account for why both low and high powered machines lag - low power machines have a lower threshold for where the engine hits its breakpoint. Furthermore, there might be issues with the game not releasing memory when a 'dynamic' object becomes 'static' or 'removed,' which would indicate a memory leak, which would also cause severe lag over time. So even a small prison built piece by piece would hit lag eventually, when the game had enough 'objects' taking up memory that may not be in the game any longer.

This is just a guess, but since a lot of people did not have this issue in Alpha 9, there might have been something changed in Alpha 10 in regards to how 'dyanamic' objects interact with each other that takes up much more processing / memory power, and is now causing lag where there was none before.

I would say it's not a memory issue, but a processor one. However, my computer says neither is used fully, so I'm unable to confirm it either way.

With what you described here, me myself experiencing a lag on ordering new materials for a new room and someone else describing a similar experience and relating it to the number of trucks on the screen, I had a hunch that it had to do with the number of available jobs your workmen have. As such, I tried building a very large field of grass after firing all my workmen, and it caused no slowdown at all. Then, I hired a single workman and immediately had the game freeze. It unfroze as soon as he had picked a job to and froze again when he was done and needed a new job. It seems my hunch was correct.

This actually is quite logical, since it's not that much of a stretch that workmen compare all jobs and pick the one that they go and do next based on this comparison. This means that unless a smart system is used, you're already at O(m x n) * O(c), where m is the number of open jobs, n is the number of workmen and O(c) is the time a single comparison costs (perhaps just generating a score, which is compared to the best score so far). It seems that distance is a part of this, which means we means there's probably a square and a square root in O(c), which means that we get an algorithm that's pretty harsh on the processor. Perhaps there's something else in the comparison as well that's causing a yet bigger increase of complexity.