I notice that in Paraview 5.10 you’re using TBB with 8 threads, so I’m wondering if changing the thread count affects the performance or if using TBB itself is the issue.
Just a heads up that up until recently, ParaView was not threaded. SLOWLY threads are being added to ParaView filters. I’m suspcious that Glyph isn’t one of them yet.
If you can turn on something called “use MPI” in setting for the backend server, don’t do it. The communication just slows you donw.
Thanks for the suggestions.
I am not using the MPI version of paraview 5.10 so I don’t have access to these.
Seems no progress since March. I spot the same behaviour, which means this is reproducible on different machines.
Animation with v5.10 is fine on Linux but is very slow on Winodws, like 3 FPS.
v5.8 works fine on both Linux and Windows.
BTW, configurations are not changed, out-of-box defaults are used for both versions. The data consists of vtk files, in which only one node is defined.
I’ve compared 5.6 to 5.11 to show a simple geometry, and 5.11 is definitely slower
no , just simple obj file
unrelated then.
Hello, i think i have the same problem as the original poster. According to my observation, it is primarily related to the number of files in the folder. The more there are, the slower the animations run. I have legacy vtk files with about 100 points each (~20kB). Animation is fluent with 20 files (timesteps), but gets excruciatingly slow with the required thousands of steps.
It works with the old paraview 5.8
Wolf
I have the same problem. ParaView 5.9 is 8 times slower than ParaView 5.8:
ParaView 5.8.1 is on time step 800 at the same time that ParaView 5.9.1 is only on time step 100.
My dataset is simple. It’s just *24 triangles, geometry-only, no color contours or glyphs or anything fancy, in EnSight case file format:
ribbit-blocks.zip (1.2 MB)
The latest ParaView 5.12 is also slow, but I have only bisected this performance issue down to somewhere between 5.8 and 5.9.
I do NOT reproduce with ParaView 5.12.0 binary release on Linux.