Major Performance Issues

[Lange]

All I can tell you is that you should be good performance-wise. If you're not, it's not your computer's fault.

Also, ditch the i7 4770 processor for something cheaper and get an SSD IMO.

Can't its a HP build and all they offered plus I got a insane deal on it anyway would of went for a i5 if it was a custom but the i7 is nice anyhow. Thanks for the idea though and im glad I should likely be okay ill see when I get it and play PR.

[Arab]

Boris, you should be in the credits man!

Well done the effort. Unfortunately, I got too damn lazy to bother with mein tests.

[Psyrus]

Hey Boris, fantastic work.

If you don't mind, since you've got it set up already for testing and we have your prior tests as benchmarks, can you test if the OCC meshes are creating a bottleneck, please?

The way to do this would be as follows:

1. Navigate to your /pr/content/ folder, extract the "objects_statics_client" (about 580MB).
2. Back up your original objects_statics_client.zip
3. Open up your command prompt (CMD)
4. Navigate to the directory you extracted to using "cd ___directory path_____"
5. • For example:

     Code: Select all

     cd C:\Program Files (x86)\EA GAMES\Battlefield 2\mods\pr\content\objects_statics_client

6. Execute the following command in that directory. It should delete about 140 files

   Code: Select all

   del *.occ /q /s

7. Re-zip your statics_client folder and overwrite the original
8. Load up the game and test FPS

=========

I don't think they're the reason, but it's another computation the CPU [GPU?] has to do where it didn't have to do it previously in <1.0, so it's worth testing.

[Heavy Death]

Boris for the president of PR!

[Boris]

Alright, ladies, calm down, it was only a few bench tests. I've been meaning to get around to doing it for weeks, just been a bit busy with things here though.

Psyrus;1952847']Hey Boris, fantastic work.

If you don't mind, since you've got it set up already for testing and we have your prior tests as benchmarks, can you test if the OCC meshes are creating a bottleneck, please?

The way to do this would be as follows:

1. Navigate to your /pr/content/ folder, extract the "objects_statics_client" (about 580MB).
2. Back up your original objects_statics_client.zip
3. Open up your command prompt (CMD)
4. Navigate to the directory you extracted to using "cd ___directory path_____"
5. • For example:

     Code: Select all

     cd C:\Program Files (x86)\EA GAMES\Battlefield 2\mods\pr\content\objects_statics_client

6. Execute the following command in that directory. It should delete about 140 files

   Code: Select all

   del *.occ /q /s

7. Re-zip your statics_client folder and overwrite the original
8. Load up the game and test FPS

=========

I don't think they're the reason, but it's another computation the CPU [GPU?] has to do where it didn't have to do it previously in <1.0, so it's worth testing.

Sure thing - not a problem running tests here. If anyone has any ideas for things to try, just shout, I'm up for it.

Did the above as described, 227 OCC files removed in all. Results:

Code: Select all

#	map		ver	load	corner x2	gpu
h	fallujah	1036	43s	55fps		43%	ambstat_* statics removed
i	fallujah	1036	44s	38fps		45%	227 occ files deleted from objects_statics_client.zip
j	fallujah	1036	43s	39fps		45%	0981 map loaded in 1036, no occ
k	fallujah	0981	32s	104fps		82%	game.lockfps 10000
l	fallujah	0981	32s	103fps		81%	game.lockfps 10000, 1036 map loaded in 0981

Test "h" I ran before removing the occlusion meshes - I just had the idea to rem out the fire/smoke effects on fallujah out of interest to see if it showed any significant change, as they have quite a big impact on fps here at times. Results show that there was no discernible difference with them removed. I had a thought that PR 1036 might have been running new type effects, causing heavier than usual demands, affecting even the 0981 version map when loaded - this doesn't appear to be the case though.

Test "i" is with the occlusion meshes removed. Big FPS drop there without them, plenty noticeable in game too as things start to get framey. Interestingly, overall GPU utilisation is about the same as with occlusion enabled, albeit producing a lower framerate now. So, I guess the CPU is being taxed more heavily here as it needs to process the extra statics no longer being occluded(?), with fps drop merely being a consequence of an exhausted CPU.

Test "j" - thought it'd be worthwhile throwing the 0981 version fallujah map in PR 1036 again just to see if there were any surprises with occlusion removed. Results show it react as good as identical to the 1036 version map.

Test "k" - wanted to make sure the system was working as yesterday by re-testing the 0981 fallujah map in PR 0981. Results show no real difference compared to earlier tests, with framerate being almost double what PR 1036 can achieve running the same map.

Test "l" - Dawned on me to run the 1036 version fallujah map in PR 0981. Results show it perform just as well as the 0981 version, with framerate nice and healthy @ 103fps, and fast loading times.

...

Ran a few tests for start-up time from launching from desktop to the lobby opening:

Code: Select all

desktop to lobby 0981	19s	19s	18s	19s
desktop to lobby 1036	28s	27s	27s	29s

It's probably not a fair test really, as there could be considerable differences in 1036 with PRLauncher involved, running file verification checks and whatnot (maybe 0981 does this too? i don't know...). Also, it's not so noticeable now on this new system I'm running, but on the old Athlon X2 before this load times were huge in PR v1, like 3 minutes to get to lobby, and 4-5 minutes to load a map. Still, for whatever reason, PR 1036 appears slower here too. I plan on running some proper tests on the old Athlon system sometime when I get it rebuilt.

EDIT: Incidentally, ran some start time tests executing PRBF2.exe directly to lobby without PRLauncher being involved:

Code: Select all

PRBF2.exe to 'lobby'	20s	21s	20s	21s

Almost 0981 load times, some 8 seconds quicker than through PRLauncher. Shame it doesn't seem possible to run the game itself without PRLauncher involved, for testing purposes - would be interesting to see the result.

...

Conclusion: As before, PR 1036 seems laboured for some reason, both in load times from desktop to lobby, during map loading, and in-game. Kinda feels like a background process chewing up an unhealthy percentage of the CPU, or a constriction in process threading, or something like that. :

[TiTo]

is poor performance a bug? My FPS goes to 20s in maps like Fallujah when i am on the move (40s if i am not). i have core i7 3630qm (2.4 ghz) and 7970m video card. Not sure if its my laptop or the bug.

I also play on my desktop. Although performance got slower i dont think i had performance issue worthy of noting.

[Boris]

is poor performance a bug? My FPS goes to 20s in maps like Fallujah when i am on the move (40s if i am not). i have core i7 3630qm (2.4 ghz) and 7970m video card. Not sure if its my laptop or the bug.

I also play on my desktop. Although performance got slower i dont think i had performance issue worthy of noting.

Not necessarily a bug, it could just be just demanding. Fallujah is a demanding map anyway, always has been, and v1.0 PR has introduced other aspects that increase demands, too. Still, there could be something sucking a bit too much juice down being overlooked, which you could call a bug I suppose.

Your main problem there is probably that 2.4GHz CPU, as it's a bit on the low side to run this game well as it stands.

[TiTo]

Not necessarily a bug, it could just be just demanding. Fallujah is a demanding map anyway, always has been, and v1.0 PR has introduced other aspects that increase demands, too. Still, there could be something sucking a bit too much juice down being overlooked, which you could call a bug I suppose.

Your main problem there is probably that 2.4GHz CPU, as it's a bit on the low side to run this game well as it stands.

even a core i7? Would 2.7 Ghz core i7 suffice?

[[FSA]IrRahman]

Boris, if your changes will made it to the future release, and 1.0 will have performance like 0.98, or close I will give you a money.

[Boris]

even a core i7? Would 2.7 Ghz core i7 suffice?

Actually, I don't know anything about that CPU you're on there to be honest, I was just basing my thoughts off the stated clock speed really (I see now though that it runs up to 3.4GHz 'Turbo' by default). It does appear to perform very respectably here though for single-thread performance, so I guess it should run PR pretty well.

[Souls Of Mischief]

[quote=""'[FSA"]IrRahman;1953002']Boris, if your changes will made it to the future release, and 1.0 will have performance like 0.98, or close I will give you a money.[/quote]

Money? Pfff... I'll suck him off.

Will post Boris test result from the previous page, just so noone misses it.

[quote="Boris""]Alright, ladies, calm down, it was only a few bench tests. I've been meaning to get around to doing it for weeks, just been a bit busy with things here though.



Sure thing - not a problem running tests here. If anyone has any ideas for things to try, just shout, I'm up for it.

Did the above as described, 227 OCC files removed in all. Results:

Code: Select all

#	map		ver	load	corner x2	gpu
h	fallujah	1036	43s	55fps		43%	ambstat_* statics removed
i	fallujah	1036	44s	38fps		45%	227 occ files deleted from objects_statics_client.zip
j	fallujah	1036	43s	39fps		45%	0981 map loaded in 1036, no occ
k	fallujah	0981	32s	104fps		82%	game.lockfps 10000
l	fallujah	0981	32s	103fps		81%	game.lockfps 10000, 1036 map loaded in 0981

Test "h" I ran before removing the occlusion meshes - I just had the idea to rem out the fire/smoke effects on fallujah out of interest to see if it showed any significant change, as they have quite a big impact on fps here at times. Results show that there was no discernible difference with them removed. I had a thought that PR 1036 might have been running new type effects, causing heavier than usual demands, affecting even the 0981 version map when loaded - this doesn't appear to be the case though.

Test "i" is with the occlusion meshes removed. Big FPS drop there without them, plenty noticeable in game too as things start to get framey. Interestingly, overall GPU utilisation is about the same as with occlusion enabled, albeit producing a lower framerate now. So, I guess the CPU is being taxed more heavily here as it needs to process the extra statics no longer being occluded(?), with fps drop merely being a consequence of an exhausted CPU.

Test "j" - thought it'd be worthwhile throwing the 0981 version fallujah map in PR 1036 again just to see if there were any surprises with occlusion removed. Results show it react as good as identical to the 1036 version map.

Test "k" - wanted to make sure the system was working as yesterday by re-testing the 0981 fallujah map in PR 0981. Results show no real difference compared to earlier tests, with framerate being almost double what PR 1036 can achieve running the same map.

Test "l" - Dawned on me to run the 1036 version fallujah map in PR 0981. Results show it perform just as well as the 0981 version, with framerate nice and healthy @ 103fps, and fast loading times.

...

Ran a few tests for start-up time from launching from desktop to the lobby opening:

Code: Select all

desktop to lobby 0981	19s	19s	18s	19s
desktop to lobby 1036	28s	27s	27s	29s

It's probably not a fair test really, as there could be considerable differences in 1036 with PRLauncher involved, running file verification checks and whatnot (maybe 0981 does this too? i don't know...). Also, it's not so noticeable now on this new system I'm running, but on the old Athlon X2 before this load times were huge in PR v1, like 3 minutes to get to lobby, and 4-5 minutes to load a map. Still, for whatever reason, PR 1036 appears slower here too. I plan on running some proper tests on the old Athlon system sometime when I get it rebuilt.

EDIT: Incidentally, ran some start time tests executing PRBF2.exe directly to lobby without PRLauncher being involved:

Code: Select all

PRBF2.exe to 'lobby'	20s	21s	20s	21s

Almost 0981 load times, some 8 seconds quicker than through PRLauncher. Shame it doesn't seem possible to run the game itself without PRLauncher involved, for testing purposes - would be interesting to see the result.

...

Conclusion: As before, PR 1036 seems laboured for some reason, both in load times from desktop to lobby, during map loading, and in-game. Kinda feels like a background process chewing up an unhealthy percentage of the CPU, or a constriction in process threading, or something like that. :[/quote]

[Psyrus]

Thanks Boris for testing the OCC meshes. Good to see they're making a decent bit of a difference in performance.

Rahman, he didn't change anything, the large FPS numbers he is getting is by running 0.98, not changing 1.0... Which is not to say this testing isn't super helpful!

[Bob12432]

So, I guess the CPU is being taxed more heavily here as it needs to process the extra statics no longer being occluded(?), with fps drop merely being a consequence of an exhausted CPU. ...



... Kinda feels like a background process chewing up an unhealthy percentage of the CPU... :

Boris you could include Cpu Load.Use Windows default System Monitor or download the Tool from this Link .

My Tests show not more than 50 % Cpu Load on *any* Core.
Even with 7-9 Fps on a Full Server playing Davros.

So pure CPU Power *cannot* be the Problem.

... or a constriction in process threading, or something like that.

That is my Guess too. Somehow the code is too FUBAR to use the existing Hardware.

[Boris]

Boris you could include Cpu Load.Use Windows default System Monitor or download the Tool from this Link .

My Tests show not more than 50 % Cpu Load on *any* Core.
Even with 7-9 Fps on a Full Server playing Davros.

So pure CPU Power *cannot* be the Problem.

Core load is 100% for the most part where GPU utilisation is less than 100%. If the GPU is taxed then it's possible there may be spare CPU cycles available (GPU bottleneck). This is a pretty rare occurrence though here, even on the very old 7800GT video cards I'm running. I'd think that anyone running any graphics card with greater than 768MB onboard RAM (so, pretty-much anything less than 7 years old) should probably not be experiencing a GPU deficiency at any point, even with all graphics options set to high (though options like high levels of AA, or high resolutions, will tax a GPU heavily).

You need to remember that the main BF2 application process is only single-threaded, so it does not, and cannot make proper use of a multi-core processor system. You may look at Windows Performance Monitor and think otherwise, but it's not actually using each of the displayed cores simultaneously; it's just being switched rapidly between them. What you're looking at there is just a representative average of load for each of the cores, not actually a true display of instantaneous load. If they did show that, then you'd see like Core1 at 100% for a split second, then Core2 at 100% with Core1 back at 0%, and so on.

It'd be worth reading through the thread in full really as this has been brought up before. I'd suggest to set PRBF2.exe affinity to a single core temporarily to get a better view of actual utilisation.

[-1-Gabe-1-]

I'd suggest to set PRBF2.exe affinity to a single core temporarily to get a better view of actual utilisation.

I did that test,,setting affinity to 1 of my two cores and I did see a lower framerate..I know it sounds odd but I tested it several times since the las PR release.

Another test that I did was so set the priority to it's highest,,which improved my fps by 10-12 frames,,The bitter side of it is that the sound gets choppy and breaks up a lot,,even though I use a Creative sound card,,not a new model,,but it does its job well..

Some1 else can confirm???

Great to see this thread pushing again,,thanks to all (Devs/players)

[iwingi]

I did that test,,setting affinity to 1 of my two cores and I did see a lower framerate..I know it sounds odd but I tested it several times since the las PR release.

Another test that I did was so set the priority to it's highest,,which improved my fps by 10-12 frames,,The bitter side of it is that the sound gets choppy and breaks up a lot,,even though I use a Creative sound card,,not a new model,,but it does its job well..

Some1 else can confirm???

Great to see this thread pushing again,,thanks to all (Devs/players)

I too have tried this and have had lower fps, 10 fps difference actually but no benchmarks to back the experience though.

[Boris]

I did that test,,setting affinity to 1 of my two cores and I did see a lower framerate..I know it sounds odd but I tested it several times since the las PR release.

Another test that I did was so set the priority to it's highest,,which improved my fps by 10-12 frames,,The bitter side of it is that the sound gets choppy and breaks up a lot,,even though I use a Creative sound card,,not a new model,,but it does its job well..

It could be that other processes running on your machine are using the same core that you set PRBF2.exe to use, with the result being them stealing a portion of the cycles. What I did here to minimise that was to set other applications that use any significant degree of CPU, like PRLauncher, Process Hacker, etc, affinity to use other cores to ensure PRBF2.exe was getting the most it could.

...

Anyhow, no work today, so did a load more faffing about. F'ing long-winded, and boring as hell, but FWIW:

Code: Select all

#	map		pr	load	hangar		gpu
m	ramiel		0981	32s	155fps		95%	0981 map loaded in 0981, high settings
n	ramiel		1036	43s	67fps		41%	0981 map loaded in 1036, high settings
o	ramiel		0981	28s	205fps		93%	0981 map loaded in 0981, low settings
p	ramiel		1036	39s	172fps		78%	0981 map loaded in 1036, low settings

All are Ramiel STD map, local server. I used the 0981 version map as PR 0981 wouldn't know how to handle the 1036 version ARF faction (couldn't be arsed messing to get it to work).

"m" - PR 0981, high video settings, position inside a hangar set looking a particular direction.

"n" - PR 1036, high video settings, same position inside hangar. Increased loading time, big fps drop, and GPU under-utilisation by comparison.

"o" - PR 0981, lowest possible video settings (for 1036 - 2,2,2,0,0,1,1,1).

"p" - PR 1036, lowest possible video settings (for 1036). Increased loading time, moderate fps drop, moderate GPU under-utilisation.

Code: Select all

#	map		pr	load	repaircrate	gpu
q	ramiel		0981	21s	257fps		93%	0981 map in 0981, low settings, no statics
r	ramiel		1036	32s	252fps		92%	0981 map in 1036, low settings, no statics
s	ramiel		0981	29s	163fps		96%	0981 map in 0981, high settings, no statics
t	ramiel		1036	40s	69fps		40%	0981 map in 1036, high settings, no statics

I removed all staticobjects (buildings, walls, etc) from the map for the next tests to eliminate them as an influence (except for the U.S. repair station which I used as the test point location).

"q" - PR 0981, low graphics settings.

"r" - PR 1036, low graphics settings. Increased load times again, but fps is not far off the PR 0981 result.

"s" - PR 0981, high graphics settings.

"t" - PR 1036, high graphics settings. Very big fps drop here, with typical increased load time.

Code: Select all

#	map		pr	load	repaircrate	gpu
u	ramiel		0981	28s	205fps		95%	0981 map in 0981, high settings, no objects
v	ramiel		1036	39s	82fps		38%	0981 map in 1036, high settings, no objects

Went further by stripping all movable objects from the map (vehicles, bipods, etc).

"u" - Lean & mean 0981 reference.

"v" - Same map in PR 1036. Very big fps drop, with usual longer load times. Hmm, what's going on? Surely with all these objects removed we should be boiling the cause it down pretty soon?

Code: Select all

#	map		pr	load	repaircrate	gpu
w	ramiel		0981	27s	208fps		95%	high settings, no objects, no overgrowth
x	ramiel		1036	38s	83fps		38%	high settings, no objects, no overgrowth

Removed all overgrowth from the map (trees, bushes, etc), too. Enviroment is almost totally empty now other than for terrain, a few rocks, and basic ground texturing.

"w" - ok...

"x" - PR 1036 - So, huge fps drop again. Why?

I noticed something odd happen. As I approached the single, lone object remaining on the map - the U.S. repair station being used as the reference point - I noticed the fps drop out all of a sudden. Move away, or look away, and fps comes back up, move closer it drops out. I ran some more tests between versions to be sure:

Code: Select all

PR 0981, high graphics settings, repair station up close = gpu load 96%
PR 1036, high graphics settings, repair station up close = gpu load 40%

I didn't record fps in the above, but the general result is about the same as for tests "w" & "x" above.

Ran the same test using low graphics settings:

Code: Select all

PR 0981, low graphics settings, repair station up close = gpu load 94%
PR 1036, low graphics settings, repair station up close = gpu load 94%

OK, so some graphics setting is causing a huge fps drop when close to objects. To cut a long story short, the switch point turns out to be the 'Level of Detail' (LOD) point (if you want to call it that) where shadows on objects start to be rendered by the engine. It's about 50 metres from the object at a guess. Every time the object come into range, fps took a nose dive.

So, I ran a bunch more tests, one for each shadows config setting:

Code: Select all

PR 1036, vehicle_depot_us lod point, shadows off,  gpu: 94%, 248fps (no switch point)
PR 1036, vehicle_depot_us lod point, shadows low,  gpu: 38%/94%, 84fps/233fps
PR 1036, vehicle_depot_us lod point, shadows med,  gpu: 38%/95%, 85fps/234fps
PR 1036, vehicle_depot_us lod point, shadows high, gpu: 38%/95%, 83fps/228fps

The two values between the "/" separator represent the difference in measurements between the switching point where shadows become enabled/disabled. What becomes apparent here, is that at any shadows setting beyond "off", CPU utilisation appears to take a big hit, causing fps and GPU utilisation to drop out. There was practically no difference as far as performance figures go between Low, Medium, and High settings. Only switching shadows off completely cured it, when using PR 1036. What's odd though really is that the only object on the map is this single U.S. repair station, so it's not like there's tons of shadows to calculate here, just a single object consisting of crates, cammo net, etc. So it just seems that as soon as shadows become enabled at all, irrespective of complexity, there will be this big CPU hit accompanying it, at least based on what I saw here in these tests.

Anyway, that's as far as I've got. I guess I need to look at how PR 0981 acts with shadows now at this point, as it might be significantly different judging by some of the results seen above.

BTW, I'm not saying this is the cause of people's problems here at all, just that it could explain part of it, at least here where I'm seeing these big fps differences between versions. This lot won't mean anything to anyone already running all low graphics settings, with shadows set to "off", but still having fps problems. But for anyone playing with shadows enabled having fps trouble, it could be worth try running without them to see if things improve much.

[Mats391]

Here is another idea you could try:
PR 1.0 introduced some new ground texture shaders, so might be worth a try running 1.0 with 0.98 shaders and otherway around.

[-1-Gabe-1-]

Code: Select all

It could be that other processes running on your machine are using the same core that you set PRBF2.exe to use, with the result being them stealing a portion of the cycles. What I did here to minimise that was to set other applications that use any significant degree of CPU, like PRLauncher, Process Hacker, etc, affinity to use other cores to ensure PRBF2.exe was getting the most it could.

Did that,,,al running processes set to core #1,, only PRBF2 set to run at core #2.. Odd to say but frames went down by 8/12 .. Any ideas???

[AfterDune]

Your efforts are much appreciated, Boris!