Entity commands speed test

[Canardia]

10000 times:
GraphicsWidth     :   0.06ms
GraphicsHeight    :   0.06ms
BackBuffer        :   0.08ms
ShowEntity        :   0.1ms
HideEntity        :   0.1ms
EntityHidden      :   0.1ms
EntityPosition    :   0.1ms
GetEntityUserData :   0.1ms
BufferWidth       :   0.16ms
BufferHeight      :   0.16ms
EntityColor       :   0.2ms
GetEntityMatrix   :   0.2ms
SetEntityUserData :   0.4ms
EntityRotation    :   0.7ms
SetEntityKey      :   2ms
GetEntityKey      :   3ms
TranslateEntity   :  13ms
FreeEntity        :  14ms
ScaleEntity       :  14ms
MoveEntity        :  14ms
PositionEntity    :  17.5ms
CreatePivot       :  21ms
CopyEntity        :  22ms
RotateEntity      :  22ms
SetEntityMatrix   :  22ms
EntityVisible     :  22ms
EntityPick        :  24ms
TurnEntity        :  28ms
PointEntity       :  28ms
CreateEmitter     :  46ms

16ms means a loss of 60FPS.

 

It seems you should not use TurnEntity, but either use EntityRotation+RotateEntity, or keep your own variable of the entity's rotation and use RotateEntity only.

 

Also GetEntityMatrix/SetEntityMatrix is a lot faster than their separate commands (Position/Rotation/Scale/Quaternion), but that was already known, or at least expected.

[Chris Paulson]

Very useful - thanks.

[cocopino]

MoveEntity        :  16ms
PositionEntity    :  18ms

 

This can't be right, can it?

[Canardia]

MoveEntity        :  16ms
PositionEntity    :  18ms

 

This can't be right, can it?

They are, I reran the test over even longer time, and it settled more accurately at:

Move:14ms, Position:17.5ms

Once the total average time starts to pump few nanoseconds up and down, I know that the initial double time (when starting up the engine and loading shaders) has been eliminated in the total timing.

[cocopino]

Strict

Framework leadwerks.engine 

Graphics 800,600

RegisterAbstractPath AppDir

If Not CreateWorld() RuntimeError "Failed to create world." 

Local cam:TCamera=CreateCamera() 

Local start:Int = 1
Local stop:Int = 50000

Local starttime:Long = MilliSecs()
Local totaltime:Long

For Local i:Int = start To stop

MoveEntity(cam, Vec3(1, 1, 1))
UpdateWorld
RenderWorld

Next

Local movetime:Float = (MilliSecs() - starttime) 

starttime = MilliSecs()

For Local i:Int = start To stop

PositionEntity(cam, Vec3(1, 1, 1))
UpdateWorld
RenderWorld

Next

Local positiontime:Float = (MilliSecs() - starttime) 

Notify("move: " + movetime + ", position: " + positiontime)

 

Running above Bmax code, PositionEntity is just a tiny little bit faster than MoveEntity (as I would expect) on my machine.

[Canardia]

You shouldn't run UpdateWorld and RenderWorld in the loop, as I only measured the speed of the commands, not the update/render time. And you shouldn't use BlitzMax, because it lacks the DLL interface which was supposed to be measured.

 

Here's my code:

#include "engine.h"
#include "Application.h"

TEntity e;
TVec3 v;
TVec4 v4;
TVec16 v16;

void test1(void)
{
//1	char s[16384]="";
//1	SetEntityUserData(e,(BP)s);
//2	TBuffer b=BackBuffer();
for(int i=0;i<10000;i++)
{
	MoveEntity(e,v);
	//PositionEntity(e,v);
	//FreeEntity(e);
}
}

int main()
{
double t1,t2,tt;
Application app;
app.Create();
RegisterAbstractPath("c:/program files/leadwerks engine sdk");
Graphics(640,480);
CreateFramework();

v=Vec3(0,0,0);
v4=Vec4(1,1,1,1);
v16=Vec16();
e=CreateCube();

int tti=0;
double ttt=0;
double ttx;
while(!KeyHit())
{
	t1=clock();
	test1();
	t2=clock();
	tti++;
	tt=(t2-t1)/CLOCKS_PER_SEC;
	ttt+=tt;
	ttx=ttt/tti;
	printf("tt=%f, ttx=%f\n",tt,ttx);
	app.Run();
}
app.Free();
}

[cocopino]

But it doesn't make any sense to run moveEntity twice (or a 1000 times) without updating.

It's faster without updating because the command doesn't do anything. Run your code, then show your scene with a camera: your cube is still in the same spot (moved only once, not 10000 times)

[Canardia]

BlitzMax code gives the same results also:

SuperStrict
Framework leadwerks.engine 
Graphics 800,600
registerAbstractPath "c:/program files/leadwerks engine sdk"
If Not CreateWorld() RuntimeError "Failed to create world." 

Local cam:TMesh=CreateCube()

Local start:Int = 0
Local stop:Int = 9999

Local t1:Long
Local t2:Long
Local tt:Long
Local ttt:Double
Local tti:Long=0
Local ttx:Double
While Not KeyHit(KEY_ESCAPE)
t1 = MilliSecs()
For Local i:Int = start To stop
	PositionEntity(cam, Vec3(1, 1, 1))
Next
t2 = MilliSecs()
Local tt:Float = t2 - t1
tti:+1
ttt:+tt
ttx=ttt/tti
Print "tt=" + tt + ", ttx=" + ttx
UpdateWorld();
RenderWorld();
Flip(0);
Wend

[Canardia]

But it doesn't make any sense to run moveEntity twice (or a 1000 times) without updating.

It's faster without updating because the command doesn't do anything. Run your code, then show your scene with a camera: your cube is still in the same spot (moved only once, not 10000 times)

I'm not completely skipping updating, but only one update per frame, which is how games are written also, so these should be relevant speed tests. Many games have thousands of objects, which need to be moved, rotated, etc... so a 16ms delay which equals a 60FPS loss is quite remarkable, especially if you can avoid one 16ms loss by knowing which commands can do the same thing faster.

[L B]

It seems you should not use TurnEntity, but either use EntityRotation+RotateEntity, or keep your own variable of the entity's rotation and use RotateEntity only.

This is so good for the new Vector3 C# system. We removed any reference to Turn or Move and use the Get/Sets implicitly.

 

i.e.:

 

cube.Rotation += 4;

 

Gets the rotation, adds it by 4 all axis, sets the rotation. All thanks to implicit C# syntax.

[Rick]

Does Move and Turn interpolate or use the time or something like that though? I thought there was something done inside these methods and it wasn't really just a straight addition or subtraction. Or maybe I was dreaming that.

[cocopino]

I'm not completely skipping updating, but only one update per frame, which is how games are written also, so these should be relevant speed tests. Many games have thousands of objects, which need to be moved, rotated, etc...

 

Your code in #8:

 

Local start:Int = 0
Local stop:Int = 9999

Local t1:Long
Local t2:Long
Local tt:Long
Local ttt:Double
Local tti:Long=0
Local ttx:Double
While Not KeyHit(KEY_ESCAPE)
       t1 = MilliSecs()
       For Local i:Int = start To stop
               PositionEntity(cam, Vec3(1, 1, 1))
       Next
       t2 = MilliSecs()
       Local tt:Float = t2 - t1
       tti:+1
       ttt:+tt
       ttx=ttt/tti
       Print "tt=" + tt + ", ttx=" + ttx
       UpdateWorld();
       RenderWorld();
       Flip(0);
Wend

 

You're calling MoveEntity(cube,vec3(1,1,1)) 9999 times and then updating once. This will make the cube move, not 9999 times (vec3(9999,9999,9999)) but only one time (vec3(1,1,1))

Don't get me wrong, the idea of doing a test like this can be very useful, but comparing commands like in your test isn't. These are not relevant speed tests: In a game, using MoveEntity more than once before an update is simply a design flaw.