1. This forum is obsolete and read-only. Feel free to contact us at support.keenswh.com

[1.190.0] Memory issues when calling another PB from a script

Discussion in 'Programming (In-game)' started by cheerkin, Apr 22, 2019.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. cheerkin

    cheerkin Trainee Engineer

    Messages:
    62
    Since reconstruction one of my drone scripts I constantly have performance issues.

    The idea was to separate the code into several modules. Targeting module encapsulates all target data acquisition logic (raycasting, SPRT's GetNearestPlayer, etc), other modules consume target feed by subscribing to this modules' data updates. Basically, targeting module serializes a batch of commands into string argument and calls other PBs.

    Before that the game handled dozens of instances with no issues. What happens now:
    1. No constant simspeed drop compared to single-pb solution.
    2. After some time GC memory starts to pile up to higher and higher values.
    3. Process memory goes up from 4GB to 9GB in seconds, then frees up, the cycle repeats.
    4. As GC flagged memory frees up, I get freeze-the-world stutter, simspeed dip, process memory goes to baseline value.
    5. After a while simpeed drops to really low values and the game is unplayable by then.

    If I comment out the other PB call and hardcode the command string with equivalent data (thus eliminating PB call part) all goes well.

    EDIT: I tried to pass data via the CustomData property instead of direct PB call and it didn't go much better. So at this point I'm not sure about OP title being accurate.
     
    Last edited: Apr 22, 2019
  2. Malware

    Malware Master Engineer

    Messages:
    9,867
    Yes. Splitting the programs like that is generally a bad idea, it's guaranteed to hit your performance one way or another. Don't do that. Just running a PB on its own has a certain impact that's worse than just calling a function.

    Since you have to deal with string parsing you're probably allocating a lot of memory constantly.
     
  3. cheerkin

    cheerkin Trainee Engineer

    Messages:
    62
    Yeah, I expected answer like this. Don't do that in PB, it's meant for simple things and scales awfully. Creating several hundreds of strings in heap per second is really that bad? I can't see how that explains 5GB GC spikes.
     
  4. Malware

    Malware Master Engineer

    Messages:
    9,867
    Oh, no, it probably isn't your whole problem. Not for 5GB GC spikes. Not unless your strings are really long :p

    but any heap allocations will be a part of poking the GC, so allocations in an often-running PB should be kept to a minimum. This is just ordinary high-performance programming considerations really, nothing special.
     
  5. cheerkin

    cheerkin Trainee Engineer

    Messages:
    62
    That was a really embarrassing case of a StringBuilder never getting cleared at particular grid setup...
     
    • Funny Funny x 1
  6. Malware

    Malware Master Engineer

    Messages:
    9,867
    It happens to the best of us... :D
     
    • Like Like x 1
Thread Status:
This last post in this thread was made more than 31 days old.