FPS Drop over time

  • mniip
    7th Sep 2013 Developer 0 Permalink
    portal data is never freed either
  • jacob2
    7th Sep 2013 Member 0 Permalink
    @mniip
    As far as I know, the save browser is just very inefficient at memory when you switch pages, but it doesn't leak and isn't constantly leaking.
  • mniip
    7th Sep 2013 Developer 0 Permalink
    i managed to score 2GiB of virtual memory
  • china-richway2
    14th Sep 2013 Member 0 Permalink

    * I take it back.

    I guess: TPT might have a varible, like max_ID. When a particle disappears TPT would change max_ID and decrease it. TPT always increases max_ID (maybe because some developers fix bugs in this way, and didn't expect the result), and so the simulator has to check particle ID = 0...max_ID, causing lag.

    I will look at source code.

     

    EDIT: I didn't guess wrongly! Simulation.cpp(3528)

    //the main particle loop function, goes over all particles.
     for (i=0; i<=parts_lastActiveIndex; i++)
      if (parts[i].type)
      {
       t = parts[i].type;

       x = (int)(parts[i].x+0.5f);
       y = (int)(parts[i].y+0.5f);

    There must be something wrong here.

    @boxmein (View Post)

    Now, am I blind?

     

    Yes I just read the load code and TPT actually don't lag anymore when a save is loaded. parts_lastActiveIndex is reset to a minimum value. Also lag stops when clear simulation, parts_lastActiveIndex is reset.

    I know no developers intend to get it constantly increased, but most developers fix bugs by getting it increased and forget to decrease it.

    Edited 5 times by china-richway2. Last: 14th Sep 2013
  • jacob1
    14th Sep 2013 Developer 0 Permalink
    @china-richway2 (View Post)
    parts_lastActiveIndex does go down when you delete particles though, and it's not possible for it to constantly increase. It can only ever go up to NPART because it only supports having the amount of particles on the screen. Also i'd like to point out that particles take a fixed amount of memory. So if you have 0, or if you have 235008, it's always the same amount of memory.

    elementCount[tempPart.type]++: actually all this does is keep track of the number of each type of particle, ex. maybe there are 183 DUST on the screen, this would tell you that. It's also always kept accurate and would never cause lag, in fact it's barely even used in the code.
  • china-richway2
    14th Sep 2013 Member 0 Permalink

    @jacob1 (View Post)

    I guess it is wrong, for example, maxmium particle ID is 100, but I guess it might be 10000 or more and cause lag. Did you debug it?

    elementCount[tempPart.type]++: No, it's not the point I want to say.

    Edited once by china-richway2. Last: 14th Sep 2013
  • Synergy
    14th Sep 2013 Member 0 Permalink

    This happens to me all the time also. If I leave it idle for awhile, it will drop to 10-20fps. Either closing/reopening the save, or closing and reopening PT will fix it.

     

    GTX 780

    i5 3570k (4.4ghz)

    8GB RAM

     

    So there's definitely no hardware limitations here. I make a lot of electronics, so maybe it's one of those particles. However I think it has happened on an empty screen too. It doesn't seem to happen if you save is actually doing something. For example, I left my processor (pt processor, not my real processor) running a program for 2 hours, and the FPS never suddenly dipped. Did that several times and it was fine. However if I left the save on idle for 20+ minutes, the frame rate would dip.

  • china-richway2
    14th Sep 2013 Member 0 Permalink

    @Synergy (View Post)

     It must be because your memory uses BRAY and disappeared very often.

  • Synergy
    14th Sep 2013 Member 0 Permalink

    That's not it. It happens on idle before any ARAY is triggered. Also happens on saves that don't use ARAY.

  • china-richway2
    14th Sep 2013 Member 0 Permalink

    @Synergy (View Post)

    I mean, the memory uses BRAY and prevents TPT from lagging.

     

    I think I should debug TPT at once.

    Edited once by china-richway2. Last: 14th Sep 2013