[0.17.25] Performance of rendering.set/get/is_* requests

Coming soon!
Post Reply
Roang
Inserter
Inserter
Posts: 27
Joined: Tue Aug 22, 2017 12:38 pm
Contact:

[0.17.25] Performance of rendering.set/get/is_* requests

Post by Roang »

The performance for calls to rendering with mods is not very good ft a large number of rendering objects are present..

I've run into this issue on my rewrite of Bottleneck for the 0.17 rendering engine.
On a large base with up to 300k Bottleneck entities (150k sprites, 150k lights) checking the validity (is_valid) or changing the tint (set_color) will take about 3ms for some of the newer entities. Due to this the rendering engine is slower to update than the old sprite style based approach that bottleneck took before.

I've created a simple demonstration mod which highlights the issue by simply creating 1 Million circles and performing simple operations on these circles.
Attachments
profiler.log
(2.35 KiB) Downloaded 65 times
rendering_perf_0.0.0.zip
(1.69 KiB) Downloaded 77 times

User avatar
Klonan
Factorio Staff
Factorio Staff
Posts: 5148
Joined: Sun Jan 11, 2015 2:09 pm
Contact:

Re: [0.17.25] Performance of rendering.set/get/is_* requests

Post by Klonan »

You are not doing the trivial optimizations:

Code: Select all

for k, v do
  if rendering.is_valid(v) then etc(...) end
end
Better:

Code: Select all

local is_valid = rendering.is_valid
for k, v do
  if is_valid(v) then etc(...) end
end
Other things like

Code: Select all

for k, v do
  rendering.set_color(v, {r = 1})
end
You can do

Code: Select all

local red = {r = 1}
local set_color = rendering.set_color
for k, v do
  set_color(v, red)
end

Roang
Inserter
Inserter
Posts: 27
Joined: Tue Aug 22, 2017 12:38 pm
Contact:

Re: [0.17.25] Performance of rendering.set/get/is_* requests

Post by Roang »

Thanks for the input, unfortunately applying these changes to the demo mod does not improve the timings noticeably.
Same goes for the Bottleneck rewrite.
Attachments
profiler.txt
(2.36 KiB) Downloaded 65 times

Roang
Inserter
Inserter
Posts: 27
Joined: Tue Aug 22, 2017 12:38 pm
Contact:

Re: [0.17.25] Performance of rendering.set/get/is_* requests

Post by Roang »

The modified demo mod.
Attachments
rendering_perf_0.0.1.zip
(1.74 KiB) Downloaded 77 times

Rseding91
Factorio Staff
Factorio Staff
Posts: 13171
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: [0.17.25] Performance of rendering.set/get/is_* requests

Post by Rseding91 »

The script rendering logic was never written to handle that amount of objects and as such it's always going to have these performance problems. You basically have to go back to creating entities at those numbers because they're the only thing which can scale that large and not have these kinds of performance problems.

Now, entities have their own problems - they're memory intensive to exist/save/load/reference in Lua but that's the price that has to be paid to keep O(1) operation times.
If you want to get ahold of me I'm almost always on Discord.

Roang
Inserter
Inserter
Posts: 27
Joined: Tue Aug 22, 2017 12:38 pm
Contact:

Re: [0.17.25] Performance of rendering.set/get/is_* requests

Post by Roang »

Ok thanks for the feedback, I will look into optimising with entities and the new entities stati.

Bilka
Factorio Staff
Factorio Staff
Posts: 3123
Joined: Sat Aug 13, 2016 9:20 am
Contact:

Re: [0.17.25] Performance of rendering.set/get/is_* requests

Post by Bilka »

See viewtopic.php?p=591699#p591699
Bilka wrote:
Tue Sep 19, 2023 11:21 am
This was optimized in 1.1: Deletion of objects where the entity target is destroyed is now instant. Furthermore, access to objects has been optimized to be O(log(n)) instead of O(n).

With 2.0, access to objects to update properties will be constant time, which is achieved by switching away from the ID system to LuaRenderObjects. This functions similarly to LuaEntities, so hopefully it should be a very familiar system.
I'm an admin over at https://wiki.factorio.com. Feel free to contact me if there's anything wrong (or right) with it.

Post Reply

Return to “Implemented for 2.0”