Bunny Mark Performance

Rayek

https://www.scirra.com/forum/performance-in-fairness_t191870

How is it possible that a web canvas-based engine is much faster than Godot in this benchmark? Is Godot's version somehow badly coded? Can it be optimized?

Rayek

The benchmarks are available here: https://github.com/colludium/bunnymark-tests

Unity's performance leaves Godot in the dust, but even the javascript version is much faster. I feel something must be wrong here.

NeoD

I guess the Godot scene instancing is very slow.

For a large amount of object it should be possible to draw the bunnies with a single 2DNode, but rewriting the bunnymark this way is beyond my skills.

Shin-NiL

Converting the logic to a CPP module can give a little boost, but still not so performant :(

https://github.com/Shin-NiL/Godot-BunnyMark-CPP

_807_

The "script" bottleneck is not in Bunny.gd is in main.gd. Is not the .instance()... if I have the time i will do my version of bunnymark...

But belive me one thing, construct is only more performant that godot in one thing:

And this thing is......: NOTHING!

(I suppose that unity should be more performant, they have more resources, and more of all...they have the "corporative structure", have their "rent close-invasive-software policy", "lot of workers", etc.... is realy to be surprised that godot is getting closer to this... We will see how much Godot 3 is closer, for now we don´t know. I would do proofs in unity, but i don´t install virus in my computer)

Rukiri

not surprised Unity fares better, I mean the capabilities are really beyond godot and that's due well they have the $$$, manpower, and resources to do so. I thought about incorporating Vulkan into Godot but to maintain it would be a hassle...

_807_

Ok, I did test:

first of all: It´s true that in Bunnymark the bottleneck is gdscript and not the renderer. The main reason is that every bunny have their own script... there are... A lot of scripts!!!

I start my bunnytest falling to 58 FPS at 3800 bunnies. (In my computer there is the mark that do the original proyect from https://github.com/colludium/bunnymark-tests

I do some changes in both scripts (main.gd and bunny.gd)

Now the bunnytest falling to 58 FPS at 4400 bunnies.

Both proofs in godot preview. If somebody want do the export proof I put the code below.

_807_

Modificated main.gd code:

extends Node2D
var bunny = preload('res://bunny.scn')
var bunnyCount = 0
var elapsed = 0
var NODE_fps
var NODE_bunnyCount
var fps
var BunnySpawnIterator
var BunnyInstance

func _ready():
	# Initalization here
	NODE_fps = get_node("fps")
	NODE_bunnyCount = get_node("bunnyCount")
	set_process(true)
	addBunny(10)

func _process(delta):
	if Input.is_action_pressed('mouse_down'):
		addBunny(10)
	elapsed = elapsed + delta
	# Update fps text once per second
	if elapsed > 1:
		fps = OS.get_frames_per_second()
		NODE_fps.set_text("FPS: " + str(fps))
		NODE_fps.set_as_toplevel(1)
		NODE_bunnyCount.set_as_toplevel(1)
		elapsed = 0

func addBunny(n):
	BunnySpawnIterator = 0
	while BunnySpawnIterator < n:
		BunnySpawnIterator += 1
		BunnyInstance= bunny.instance()
		add_child(BunnyInstance)
		bunnyCount = bunnyCount + 1
	var count = "Bunnies: " + str(bunnyCount)
	NODE_bunnyCount .set_text(count)

_807_

Modificated bunny.gd code:

		extends Sprite
		var v = Vector2(randi() % 200 + 50,randi() % 200 + 50 )
		const ay = 980
		var pos
		
		func _ready():
			set_pos(Vector2(50,50))
			pos = get_pos()
			set_process(true)
			
		func _process(delta):
			v.y += ay * delta
			pos += Vector2(v) * delta
			if pos.y > 600:
				v.y *= -0.85 
				pos.y = 600
				if randf() > 0.5:
					v.y = -(rand_range(50,1150))
			elif pos.y < 0:
				v.y = 0
				pos.y = 0	
			elif pos.x > 800:
				v.x = -v.x
				pos.x = 800
			elif pos.x < 0:
				v.x = abs(v.x)
				pos.x = 0
			set_pos(pos)

_807_

I think that I can gain some extra FPS with simplified code. But I´m not continue with this. Simply understand that is you want have more that 4000 objects every one with their own script you need to code very very very performant-thinking. More that 4000 _process funcs allocating memory every tick is some that I thing "insane" (in gdscript in c++ etc...)

Some thing that i do in the script:

		1) eliminate redundant pos=get_pos()
		2) change float x and y values to a Vector 2
		3) cange If/elif positions (bunny touches more times the floor that the walls
		4)..... i don´t remember more, compare the codes.

And I´m sure that I can do better (An I´m not a programmer, I´m a designer).

If this "Bunnymark" check performance, you need to do the code performant. But I think this test is not representative of nothing.

NeoD

@807 It would be possible to go without this bunny script. The official demo called "Shower of bullets" is an example of a script who fits better to a large number of objects.

Here is the main comment of the bullet.gd file.

# This demo is an example of controling a high number of 2D objects with logic and collision without using scene nodes.
# This technique is a lot more efficient than using instancing and nodes, but requires more programming and is less visual

_807_

Yes, but you need to battle with godot internal servers and the sugar of godot is the easiest code, the fast-develop, if you need to do something like the logic of "Shower of bullets" maybe is better to rework slowly your game design. How many bullet-hell have 4000 "scripted" bullets in screen? Enought pixels for the bullets? ;) (Note: the exported version of the reworked bunnymark handle 7000 bunnies at 60 fps in my I5)

Realy, if somebody considerate to move from one engine to other by tests like "bunnymark" i told to him that stop procastinate a make NOW that f***** game.

_807_

Bad news with the "shower of bullets". I do the test with this method and "bunnyscript" (there is no frame drops in instance objects with the .new() and the performance is the same.

A question: There is any option to undo the right button "delete all" option?... I do that thinking that I only delete a function and the entire script goes "black"...

Shin-NiL

@807 said: Bad news with the "shower of bullets". I do the test with this method and "bunnyscript" (there is no frame drops in instance objects with the .new() and the performance is the same.

Yeah, I still thinking that the bottleneck is on_process. Even using the "shower of bullets" approach you continue iterating over each bunny and executing its logic.

Maybe this little experiment might interest you.

_807_

Yes... Before start use Godot I did a lot of experiment like this, and I have a lot of "intuition" conclusions. For loop ----> slow, local variables ----> slow , get_node -----> very slow. And I have "performant" scripts now, but there is something in process and fixed_process, that is not performant in certains limits. I think that it can be related with the frame time, vsync or something like this... Example: The bunnyscript with "shower of bullet" aproach goes at 60 FPS until it down to 30 FPS directly. It make sense that if you have a lot of scripts it can handle better the "idle" time (the original script goes down frame by frame), but the results are basically the same: at certains numbers of nodes or at certain number of aritmetics, the engine goes down... No matters you have to render something or not (Maybe the servers?). I try bunnyscript without "bunnys" and the performance is equally. Other not performant things are "Light2d" and "Add" mix mode... But all this things are no relevant to a lot of games. I use construct for 2 years and the develop speed of godot is huge compared to that, the renderer equally, you can execute the games in old computers (not like engines with directX and scripts compiled like GM and jojo, or unity, but a lot of performance compared with construct and Node webkit and other "html5" based like this). If you have limits in mind at the moment to start develop there is nothing that you can not do (In 2d, 3d for my is "fog of war"), and is a good habit start thinking in the basics of the game, and writing the code tiny from beggining.

P.D. If I re-do the Shower of bullets bunnyscript i put that here... godot have a very very very irritating feature that I have discovered today, the "delete all" in script, this feature is like a kick in the balls, like insulting a mother or something worst!!!!

_807_

Here we are:

"Shower of bunnys", same performance that actual bunnyMark but don´t stutters at instantiate bunnys:

extends Node2D
#"Shower of bunnys"
#Godot 2.1.3
#Mix between "Shower of bullets" demo and "bunnyMark" test for Godot.
#Change main.gd in bunnymark with this script.

var bunnyCount = 0
var countConcatenate
var elapsed = 0
var fps
var NODE_fps
var NODE_bunnyCount
var bunnys = []
var mat #matrix32
var bunnytexture = preload("res://sprite-sheet0.tex")

class Bunny:
	var pos = Vector2()
	var body = RID()
	var v = Vector2(randi() % 200 + 50,randi() % 200 + 50 )
	const ay = 980

func _ready():
	NODE_fps = get_node("fps")
	NODE_bunnyCount = get_node("bunnyCount")
	set_fixed_process(true)
	set_process(true)
	addBunny(10)

func _fixed_process(delta):
	if Input.is_action_pressed('mouse_down'):
		addBunny(10)
	elapsed = elapsed + delta
	if elapsed > 1: # Update fps text once per second
		fps = OS.get_frames_per_second()
		NODE_fps.set_text("FPS: " + str(fps))
		NODE_fps.set_as_toplevel(1)
		NODE_bunnyCount.set_as_toplevel(1)
		elapsed = 0

func _draw():
	for bunnyiterator in bunnys:
		draw_texture(bunnytexture, bunnyiterator.pos)

func _process(delta):
	mat = Matrix32()
	for bunnyiterator in bunnys:
		bunnyiterator.v.y += bunnyiterator.ay * delta
		bunnyiterator.pos += bunnyiterator.v * delta
		if bunnyiterator.pos.y > 600:
			bunnyiterator.v.y *= -0.85 
			bunnyiterator.pos.y = 600
			if randf() > 0.5:
				bunnyiterator.v.y = -(rand_range(50,1150))
		elif bunnyiterator.pos.y < 0:
			bunnyiterator.v.y = 0
			bunnyiterator.pos.y = 0	
		elif bunnyiterator.pos.x > 800:
			bunnyiterator.v.x = -bunnyiterator.v.x
			bunnyiterator.pos.x = 800
		elif bunnyiterator.pos.x < 0:
			bunnyiterator.v.x = abs(bunnyiterator.v.x)
			bunnyiterator.pos.x = 0
		mat.o = bunnyiterator.pos
		Physics2DServer.body_set_state(bunnyiterator.body, Physics2DServer.BODY_STATE_TRANSFORM, mat)
	update()

func addBunny(number):
	for i in range(number):
		var newbunny = Bunny.new()
		newbunny.body = Physics2DServer.body_create(Physics2DServer.BODY_MODE_STATIC)
		Physics2DServer.body_set_space(newbunny.body, get_world_2d().get_space())
		newbunny.pos = Vector2(50,50)
		mat = Matrix32()
		mat.o = newbunny.pos
		Physics2DServer.body_set_state(newbunny.body, Physics2DServer.BODY_STATE_TRANSFORM, mat)
		bunnys.append(newbunny)
		bunnyCount = bunnyCount + 1
	countConcatenate = "Bunnies: " + str(bunnyCount)
	NODE_bunnyCount .set_text(countConcatenate)

_807_

This test is amuse me... It can be posible make _process calculation in a shader?... Maybe this up performance.

Shin-NiL

Hey @807 I've just discovered something interesting. The getters, setters and properties accessing seems to be a little slow. Using my original code I got:

Changing it to avoid using Vector2 properties:

extends Sprite

var velocity_x = 0
var velocity_y = 0
var gravity = 3
var max_x = 640
var min_x = 0
var max_y = 480
var min_y = 0


func _ready():
	var tex = preload("res://wabbit_alpha.png")
	set_texture(tex)
	velocity_x= randf() * 10
	velocity_y = rand_range(5, 10)
	set_process(true)
	
func _process(delta):
	var pos = get_pos()
	var pos_x = pos.x
	var pos_y = pos.y

	pos_x += velocity_x
	pos_y += velocity_y
	velocity_y += gravity
		
	if (pos_x > max_x):
		velocity_x*= -1
		pos_x = max_x
	elif (pos_x < min_x):
		velocity_x*= -1
		pos_x = min_x
		
	if (pos_y > max_y):
		velocity_y *= -0.8
		pos_y = max_y
		if (randf() > 0.5):
			velocity_y -= randf() * 12;
		 
	elif (pos_y < min_y):
		velocity_y = 0;
		pos_y = min_y;
		
	set_pos(Vector2(pos_x, pos_y))

I got:

_807_

Shin_NiL:

Great discovery!!! You are right, bunnymarkt resolved... is not the math, is not the script languaje, is not the render... is the set_get, and specifically the "set" function. If change to comment the "get_pos" line the performance is same (little better) but If I turn on comment in the line of "set_pos" performance ups * 1,5 (edited, more proofs done), so the problem are not global vs local vars, aritmetics (edited: not sure, more proofs done!), excesive number of nodes, excesive number of scripts with process turn on, if-elif order or rendering bunnys, the bottleneck is set_pos, great discovery!

This test make me crazy because I test gdscript with construct 2 events before do change of engine and godot results for pure loops and aritmetics smash construct javascript by far, so I wasn´t understanding this..... But in my tests only do things like while blablabla: var +=1 etcetc... didn´t use getters and setters :innocent: :neutral:

_807_

Shin_NiL:

Only for curiosity I made your velocity test in Love2d.... and the results are depresive... I put the code:

	counter = 0
	tiempo_inicio = love.timer.getTime()
	loop1 = 0
	loop2 = 0
	loop3 = 0
	for i=1,10 do
	    loop1 = loop1 + 1
	    for i=1,3200 do
	        loop2 = loop2 + 1
	        for i=1,3200 do
	        loop3 = loop3 + 1
	        counter = counter + 1
	        if counter > 50 then
	            counter = 0
	        end
	        end
	    end
	end
	tiempo_fin = love.timer.getTime()
	tiempo_total = tiempo_fin - tiempo_inicio
	function love.draw()
	    love.graphics.print(tiempo_inicio, 400, 250)
	    love.graphics.print(loop1, 400, 275)
	    love.graphics.print(loop2, 400, 300)
	    love.graphics.print(loop3, 400, 325)
	    love.graphics.print(tiempo_fin, 400, 350)
	    love.graphics.print("Tiempo total en segundos", 400, 375)
	    love.graphics.print(tiempo_total, 400,450)
	end

Results are.... Godot need 35 seconds in editor and 27 seconds in export release without debug mode, no matters if use while or for loop. Love2d need 0,16 seconds in the same operation. Obviously there´s something wrong with that. Is Interpreted-Lua 150 times faster than Gdscript/python?