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.
[0.17.25] Performance of rendering.set/get/is_* requests
[0.17.25] Performance of rendering.set/get/is_* requests
- Attachments
-
- profiler.log
- (2.35 KiB) Downloaded 90 times
-
- rendering_perf_0.0.0.zip
- (1.69 KiB) Downloaded 99 times
Re: [0.17.25] Performance of rendering.set/get/is_* requests
You are not doing the trivial optimizations:
Better:
Other things like
You can do
Code: Select all
for k, v do
if rendering.is_valid(v) then etc(...) end
end
Code: Select all
local is_valid = rendering.is_valid
for k, v do
if is_valid(v) then etc(...) end
end
Code: Select all
for k, v do
rendering.set_color(v, {r = 1})
end
Code: Select all
local red = {r = 1}
local set_color = rendering.set_color
for k, v do
set_color(v, red)
end
Re: [0.17.25] Performance of rendering.set/get/is_* requests
Thanks for the input, unfortunately applying these changes to the demo mod does not improve the timings noticeably.
Same goes for the Bottleneck rewrite.
Same goes for the Bottleneck rewrite.
- Attachments
-
- profiler.txt
- (2.36 KiB) Downloaded 86 times
Re: [0.17.25] Performance of rendering.set/get/is_* requests
The modified demo mod.
- Attachments
-
- rendering_perf_0.0.1.zip
- (1.74 KiB) Downloaded 99 times
Re: [0.17.25] Performance of rendering.set/get/is_* requests
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.
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.
Re: [0.17.25] Performance of rendering.set/get/is_* requests
Ok thanks for the feedback, I will look into optimising with entities and the new entities stati.
Re: [0.17.25] Performance of rendering.set/get/is_* requests
See viewtopic.php?p=591699#p591699
Bilka wrote: ↑Tue Sep 19, 2023 11:21 amThis 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.