Severe performance regression on DTS-T MAP12

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Severe performance regression on DTS-T MAP12

Post by drfrag »

All versions since 2.2 affected (1.9.1 was not). Both hardware and software renderers. On DTS-T.pk3 MAP12 my fps went from 50 to 1 (this is a core2 duo).
It's something i cherry-picked since ZDoom LE 2.8.1b (between those dates, FEB-SEP 2016). So my gzdoomle branch could be of help.

https://www.doomworld.com/idgames/level ... wads/dts-t
https://github.com/drfrag666/gzdoom/commits/gzdoomle
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Severe performance regression on DTS-T MAP12

Post by Rachael »

I shouldn't have to say things like this, but positive reinforcement is definitely needed on this issue -

Thank you for providing a direct link to the mod in question, and for doing it without me asking for it. That makes it a lot easier to investigate.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Severe performance regression on DTS-T MAP12

Post by Rachael »

So the problem here is caused by the laser beams on this map. As I suspected, the transition to the new ZScript VM is why the performance dropped between 2.1 and 2.2, as it seems it is not gracefully handling the constant movement and creation and destruction of so many actors at once. (note ZScript still wasn't actually available at the time, but the VM for it was already in the engine at this point)

Unfortunately I don't know if this can be fixed engine-side. I know ZDoom/GZDoom never actually handled heavy actor movement with rapid actor creation/destruction very gracefully, anyhow. Disabling the laser beams restores the FPS to very high levels.
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: Severe performance regression on DTS-T MAP12

Post by Major Cooke »

...Well this just might be a contributing factor too... I know, that's more on the memory side of stuff but still.

:blergh:
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Severe performance regression on DTS-T MAP12

Post by Rachael »

It is just a memory issue, and it has nothing to do with the fact that when the LaserBeam.wad file is removed or renamed, that FPS is completely normal on that map. Same thing happens when the map gets hit with a 'freeze' cheat. The WAD-in-ZIP layout has actually nothing to do with the performance issues here, in this case, or if it does it's minor and insignificant.
Blue Shadow
Posts: 4949
Joined: Sun Nov 14, 2010 12:59 am

Re: Severe performance regression on DTS-T MAP12

Post by Blue Shadow »

The laserbeam WAD was updated a year and a half ago to improve performance. Give it a try, if you're interested.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: Severe performance regression on DTS-T MAP12

Post by drfrag »

Thanks, that fixed the problem. It could not be the new VM since ZDoom LE uses the same as ZDoom 2.8.1. I've tried reverting some commits since 2.8.1b but it's still the same (trial and error, not that much stuff there really). So i've got no idea of where the slowdown was introduced. Even when this wad is fixed i bet it will affect other wads.
Probably unrelated but removing the BEHAVIOR lump i get some errors and the map won't run.

Code: Select all

map12 - Deck 1: Research/Cargo

Removing 0-length line 4
Removing 0-length line 5
Removing 0-length line 12
Removing 0-length line 13

Line 18 has invalid vertices: 30 and/or 65535.
The map only contains 2549 vertices.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Severe performance regression on DTS-T MAP12

Post by _mental_ »

Without BEHAVIOR lump Doom map format is assumed instead Hexen. So this lump must be present but it can be empty.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: Severe performance regression on DTS-T MAP12

Post by drfrag »

Of course, i forgot that. I've tried the empty BEHAVIOR trick and it runs but still slow. Still no idea of what changed but it's not ACS related.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Severe performance regression on DTS-T MAP12

Post by _mental_ »

If you can easily distinguish fast and slow versions then use git bisect on ZDoom between tag 2.8.1 (good) and the latest (bad). You will find the fist bad one in ~12 steps.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: Severe performance regression on DTS-T MAP12

Post by drfrag »

A blind binary search would be my last resort. It would be much faster doing the search between 2.8.1b and 2.8.2 but i've reviewed everything and there's nothing there. Moreover the LE 95 version is still fast and the commits are mostly the same so...

I think it's a compiler specific thing, i've switched to GCC 4.9.2 from 4.6.1 (i think ZDoom used VS 2005). Possibly undefined behavior in the garbage collector i guess so actor destruction is slower affecting performance in extreme cases.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Severe performance regression on DTS-T MAP12

Post by Graf Zahl »

drfrag wrote:A blind binary search would be my last resort.

I beg your pardon? That is normally the fastest and most efficient way to find a problem spot in a larger number of sequential changes.


In any case, the problem causer in this case is relatively obvious: The beam particles have not been using the NOINTERACTION flag resulting in full movement processing each frame.
And after 2.8.1, there has indeed been additions to that code that made it slower - but it wasn't the VM but the portals!

Checking the 'stat think' time of this mod between ZDoom 2.8.0 and a recent GZDoom shows a jump fron 7.6 ms to 10.ms for me, obviously on slower systems those added 3 ms can put the system over the edge and make performance break down. With the new laserbeam version (which actually uses NOINTERACTION) think time drops to 0.3 ms per frame, which shows how expensive running full collision detection can be for 1000 actors per frame if they move fast enough to divide their movements into multiple steps.
Doing some calcuations on the data here with a radius of 2 and velocity of 4 gives 5(!) movement iterations per frame. I don't think we need to go any further to see what went wrong here.

In summary it must be said that the original was just broken by design and the implications can definitely be felt.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: Severe performance regression on DTS-T MAP12

Post by drfrag »

Thanks very much for your explanation. That makes a lot of sense and explains the slowdown in GZDoom 2.2.
Compiling here takes up to 20 minutes so i thought it was better to investigate, but i didn't port that portal stuff to LE. And i bet it's the same slowdown.
Finally i've made the bisect and as expected all revisions (not that many here) were slow, the older fast LE version (gcc 4.6.1) when compiled with gcc 4.9.2 now is slow. Could be the -mtune=pentium2 option combined with the old compiler? (now it's useless).
So frankly no idea of what's going on here.
Edit: I didn't notice the NOINTERACTION flag was used only for the generators in the old version but i noticed that generation stopped when their speed was low.
Edit2: I.R. developer. I.R. very clever.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Severe performance regression on DTS-T MAP12

Post by Graf Zahl »

What's going on here is really quite simple. The code was extremely slow to begin with. But several independent factors had an effect on it, making it even slower. But like with many things, the original was just below the threshold of the slowness being noticable while the newer one just crossed that threshold.
I suggest running 'stat think' with both versions and see how the values compare. That gives you more meaningful results to see how much of an impact the new compiler has.

Also let's not forget that unoptimized debug builds really choke on this code badly.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: Severe performance regression on DTS-T MAP12

Post by drfrag »

Thanks again. I've recompiled the latest version (2.8.2) with the old gcc and can confirm it's a compiler thing. The difference is massive, stat think with the modern compiler gives 160 ms vs 20 ms with the old compiler. For VS and GZDoom must be the same so some strange thing is happening somewhere and could be worth investigating this further.
Last edited by drfrag on Wed Feb 28, 2018 3:00 pm, edited 1 time in total.
Post Reply

Return to “Closed Bugs [GZDoom]”