Performance Issues

Discussion in 'General Discussion' started by Money Mike, Apr 6, 2018.

Thread Status:
Not open for further replies.
  1. Manxis

    Manxis Guest

    I had been having a horrible glitch day. I checked my resources and found my CPU at 32%, GPU at 28% but disk was at 60% and memory was at 92% with SOTA taking almost 2 Gb. Ram swapping right?, so I completely rebooted the system to see what I get from a fresh boot. My system was running a steady 25% ram utilization with 11.6 Gb available of 16 Gb. It was unchanging so I ran my video capture tool so I could record it and then I ran SOTA. The system memory utilization went in to the 50% range and hovered in that area as long as I didn't zone. The instant I zoned the utilization would usually sneak up a percent or two and sometimes it would stay there. At 65% memory utilization my questing got TOTALLY snookered AGAIN and I had been recording my questing efforts for YouTube for over 2 hours now. I was bored so I cracked out the IL editor, killed the video recorder and started analyzing the game code for anything I could find that might support memory leaks. Thats when I noticed a rather loose attitude toward string variables within the code. Toss one of those immutable strings in a loop and you can have some real fun.
    Its by no means THE answer. I have a lot of analyzing to do. I figured since I couldn't quest I'd hack. but in the process I completely eliminated glitching by rebooting my system and I was able to watch memory utilization creep up with zoning.
     
  2. Manxis

    Manxis Guest

    He's absolutely right! Especially with Game development. A game with a bad memory leak might be improved by adding memory but that's only because you've given it more memory to leak, the same problem exists and will eventually cause the same problems again. All you've done by adding resources is cause the game to take a little longer to cause system degradation.

    This is especially true of game development today. Used to be that the game developers had to code everything themselves. Today they only code little modules that are only executed during specific events like when you shoot or click on a door, etc. So the first problem is they loose a sense of "The system" as a whole because their view is only on the event module and not how things interact. Its kind of like sending kids to the playground and only monitoring the behavior of a single child at a time and not paying any attention to the interactions between children.

    The other thing to consider is some of the developers are very old school. 1980's old school. I started then too and have had to learn some hard lessons because of it. Basic didn't have "Immutables". Things like strings were bulky but they didn't self replicate like they do today. In 6502, 6809 and early 80x86 assembler, memory leaks weren't much of an issue since you weren't reallocating ram, you just used what was there and since C & C++ focused on linked lists for strings, most of the memory leak issues came from bad Malloc usage or just bad memory usage. Today you can get a memory leak just by using a string concatenation and if you toss that in any loop, say goodbye to your ram. And there are all kinds of third party bits a pieces that developers can buy online to avoid having to write the code themselves which of course is very attractive to most. I've found at least one of those in Sota so far. The problem with those is you don't know what the problems with those is! And whats worse, many of those third party assets have been built on other third party assets with their own problems! I once had to debug why a popular help-desk application was so dreadfully slow. When I disassembled the JDBC driver I found modules from 4 different manufacturers, all with their own coding styles and approaches and duplicated code everywhere, all calling each other. It was a real POS. Throw all the resources you want at something like that, your still toast!
     
  3. Serafina

    Serafina Portalarian Emeritus

    Messages:
    1,302
    Likes Received:
    1,658
    Trophy Points:
    113
Thread Status:
Not open for further replies.