It doesn't seem to be so much an improvement to be honest, such a test will
be more or less about nothing. It shouldn't be full testing, it should be
per-area time measuring. For example, we could speedup viewport opengl
display but accidentally slowdown dependency graph and having just an
I didn't say it's difficult, i only mentioned that it is to be thought much
more careful defining which exact information is useful for us and how to
gather it.
On Wed, Jun 10, 2015 at 1:25 PM, Campbell Barton ideasma...@gmail.com
wrote:
Hi Martijn, think its fine to have more comprehensive
Hi Sergey,
I agree that the overall timer + playback has limited use cases compared to
proper full instrumentation of all parts of blender.
But I don't really suggest it does.
What things would be good to be able to make this thing do in order to
extract better information?
Martijn
On Wed, Jun
Hi Sergey,
On Wed, Jun 10, 2015 at 12:47 PM, Sergey Sharybin sergey@gmail.com
wrote:
It doesn't seem to be so much an improvement to be honest, such a test will
be more or less about nothing. It shouldn't be full testing, it should be
per-area time measuring. For example, we could speedup
Hi Martijn, think its fine to have more comprehensive performance tests
(which can include extending, bpy.ops.wm.redraw_timer or add related
operators to give more comprehensive info).
This seems like 2 separate projects,
- ability to perform tests and collect feedback.
- extend existing
It would be nice to be able to separate this total performance time to
sub-costs, otherwise it would indeed difficult to make out something
out of that number apart from performance changed - which indeed
says little, performance changes with every change.
On 10 June 2015 at 13:38, Sergey
Hello everyone,
Blender is evolving at a rather nice pace currently but I feel we could use
better measurements to guide its the performance aspect of this a bit
better.
Some 3d games (like quake) have a feature called “timedemo” this basically
runs the game as fast as the hardware will let it
Hi,
We actually have something like this already
bpy.ops.wm.redraw_timer()(i.e. Ctrl-Alt-T)
This can be used for testing how long it takes to do things like redrawing
the screen/area/region(?) 10 times, and also for things like animation
playback and undo/redo times. If you need anything
Martijn, thinking of something similar to current Debug Timer operator (or
even an extension of it) which will perform some operation N times (N =
10) and report total/average time on it. The operations could be:
- Viewport draw (which we already have)
- Full scene depsgraph evaluation
- Scene
