Daz Studio needs minutes to shut down

pixelquack

her on my 32GB Ryzen + M.2 rig when I close DS, I see it lingering in Task Manager for *minutes*, slowly decreasing memory usage. Occasionally I kill it since the scene was saved, but I like to restart for rendering, so, why does it do that?

Richard Haseltine

Yes, with content that has a lot of linked properties the clean-up can take a while, You can start a new isntance of Daz Studio in the meantime (using the command line, or a prepared shortcut from the linked script) Daz Studio Pro 4.12 - instances

fred9803

I raised this issue a few days ago and people said they didn't see it happening, at least not in the latest itteration of DS. It does happen for me the way you describe it pixelquack, as a background process rather than an open app.

It's no big deal. I just stop the process and it's full steam ahead with the next render.

Klimax

Inefficient objects management. (On any cleanup destructor has to be run on all elements and associated stuff, which can take a lot time) I saw it when I made scene with 121 figures. Also it causes DAZ to be really inefficient with memory (large fragmentation).

cridgit

Redacted

Richard Haseltine

cridgit said:

I've also had this problem for the past few months. Probably 2 minutes or so. Also when I have a scene and select New Scene it takes 1-2 minutes on "deleting objects".

They definitelay changed something in one of the more recent versions because this behaviour is new.

I don't like to kill the process because the Content DB (Postgresql) might hiccup.

The behaviour is not new, but it does depend on the bumber of properties and links on the items in the scene.

Klimax

Richard Haseltine said:

cridgit said:

I've also had this problem for the past few months. Probably 2 minutes or so. Also when I have a scene and select New Scene it takes 1-2 minutes on "deleting objects".

They definitelay changed something in one of the more recent versions because this behaviour is new.

I don't like to kill the process because the Content DB (Postgresql) might hiccup.

The behaviour is not new, but it does depend on the bumber of properties and links on the items in the scene.

Best way to fix it would be to use memory pool to contain objects. On shutdown only pool would need explicit tear down and thus no need to iterate over all objects and destroying them (also it would fix inefficient memory allocation). Alternatively, one can abuse fact that application shut down is under way and simply skipping all the destructors (Would need custom destructors to check what is going on).

Richard Haseltine

Klimax said:

Richard Haseltine said:

cridgit said:

I've also had this problem for the past few months. Probably 2 minutes or so. Also when I have a scene and select New Scene it takes 1-2 minutes on "deleting objects".

They definitelay changed something in one of the more recent versions because this behaviour is new.

I don't like to kill the process because the Content DB (Postgresql) might hiccup.

The behaviour is not new, but it does depend on the bumber of properties and links on the items in the scene.

Best way to fix it would be to use memory pool to contain objects. On shutdown only pool would need explicit tear down and thus no need to iterate over all objects and destroying them (also it would fix inefficient memory allocation). Alternatively, one can abuse fact that application shut down is under way and simply skipping all the destructors (Would need custom destructors to check what is going on).

We don't really hav a full  grasp of the technicalities, so should be wary about saying that such-and-such is the solution.