www.factorio.com
https://forums.factorio.com/
I actually found some additional things right after I said that so now in 0.16 it's around 280% faster. In 0.15 it takes 10 MS of prepare time and in 0.16 it takes 3.5 MS of prepare time.sillyfly wrote:Wube's optimization philosophy - saving 50% is only a slight improvementRseding91 wrote: ... it may help slightly ... takes half the time ...
Keep up the excellent work guys.
280% faster ! We are now able to reverse time \o/Rseding91 wrote:I actually found some additional things right after I said that so now in 0.16 it's around 280% faster.
Thanks, that sounds goodRseding91 wrote:I actually found some additional things right after I said that so now in 0.16 it's around 280% faster. In 0.15 it takes 10 MS of prepare time and in 0.16 it takes 3.5 MS of prepare time.
Not this again... it all depends how you calculate %. If it's current time / old time or old time / current time.Koub wrote:280% faster ! We are now able to reverse time \o/Rseding91 wrote:I actually found some additional things right after I said that so now in 0.16 it's around 280% faster.
I was simply mousing over the blueprint in the quickbar with the show-time-used debug option enabled.JamelBF wrote: Thanks.Very useful.
If 0.16 it takes 3.5MS.
How you think about 0.17?Can you share your test please
But isn't it 180% faster then? Or 280% as fast?Rseding91 wrote:10 MS / 3.5 MS = you can do 3.5 MS 2.8 times (280% of the work that's done now could be done before it reaches the time spent before) or you calculate it as 3.5 MS / 10 MS = it takes only 35% as much time as it did before.
And now place the blueprint. You get a nice "Server is not responding" message while the server places the blueprint.Mimos wrote:Factorio 15.37
I encountered significant slowdowns when using large blueprints. Both just mouseovering the blueprint item and also moving the ghost over the map. It causes a lot less slowdown if it is built and in operation.
Single player, empty map:Multiplayer, big, slow factory, me being the server:
- Mouseover zoomed in: fps drop (60 to 50), ups ok.
Mouseover zoomed out: fps drop (60 to 40), ups ok.
- Render preparation/Gui render preparation going up to 13 from 0.5/0.1
Render/Gui render going up to 6/5 from 0.5/0.1Placing it zoomed in: fps drop (60 to 40), ups ok.
- Render preparation/Gui render preparation going up to 14 from 1.5/0.1
Render/Gui render going up to 9/5 from 3.8/0.1Placing it zoomend out: fps drop (60 to 30), ups ok.
- Render preparation/Game render preparation going up to 21 from 0.5/0.3
Render/Game render going up to 3.7/3.5 from 0.8/0.7
- Render preparation/Game render preparation going up to 24 from 1.6/1.4
Render/Game render going up to 6.8/6.7 from 3.7/3.6Maybe you can somehow speed up blueprints to have about the same speed as real buildings.
- for me: fps and ups drop from about 40 to 20.
other players (having faster pcs): unplayable, hardly reacting to inputs.
Gnark wrote:Hi,
I really like my game but this is now significantly dropping on FSP.
Do you know what I can do to keep going with this save ?
Thanks a lot.
Thanks for looking at it. If I replace somme belt with underground one ... will it help ?Rseding91 wrote:Gnark wrote:Hi,
I really like my game but this is now significantly dropping on FSP.
Do you know what I can do to keep going with this save ?
Thanks a lot.
You simply have a ton of belts. There's nothing new in that to optimize - if you want it to run faster you just can't build that much.
That will help. There are also tons of belt optimizations in 0.16.Gnark wrote:Thanks for looking at it. If I replace somme belt with underground one ... will it help ?Rseding91 wrote:Gnark wrote:Hi,
I really like my game but this is now significantly dropping on FSP.
Do you know what I can do to keep going with this save ?
Thanks a lot.
You simply have a ton of belts. There's nothing new in that to optimize - if you want it to run faster you just can't build that much.
I want to keep a belt factorie and not a robot one.
Blueprints have to check every entity to see if there is something beneath it that conflicts or needs to be deconstructed (with shift pressed). It can probably be optimized (e.g. pre-compute a single mask where trees need to be deconstructed instead of checking per entity) but as is a render slowdown isn't surprising.Xeteth wrote:Found something new that absolutely tanked my FPS/UPS today.
I am making a 'Coal Bunker' which has a ton of storage chests - when I hold the blueprint in hand ready to place it my FPS/UPS takes a massive hit. It seems the slow down is caused under "Game Render Preparation".
The map otherwise works at 60/60.
That part of the logic is actually minimal. It's the copying of the blueprint in hand, adjusting it to the correct world position, rotating every entity, setting each entity up, and then destroying each one after it's rendered that takes the majority of the time.mrvn wrote:Blueprints have to check every entity to see if there is something beneath it that conflicts or needs to be deconstructed (with shift pressed). It can probably be optimized (e.g. pre-compute a single mask where trees need to be deconstructed instead of checking per entity) but as is a render slowdown isn't surprising.Xeteth wrote:Found something new that absolutely tanked my FPS/UPS today.
I am making a 'Coal Bunker' which has a ton of storage chests - when I hold the blueprint in hand ready to place it my FPS/UPS takes a massive hit. It seems the slow down is caused under "Game Render Preparation".
The map otherwise works at 60/60.
Rseding91 wrote:That part of the logic is actually minimal. It's the copying of the blueprint in hand, adjusting it to the correct world position, rotating every entity, setting each entity up, and then destroying each one after it's rendered that takes the majority of the time.mrvn wrote:Blueprints have to check every entity to see if there is something beneath it that conflicts or needs to be deconstructed (with shift pressed). It can probably be optimized (e.g. pre-compute a single mask where trees need to be deconstructed instead of checking per entity) but as is a render slowdown isn't surprising.Xeteth wrote:Found something new that absolutely tanked my FPS/UPS today.
I am making a 'Coal Bunker' which has a ton of storage chests - when I hold the blueprint in hand ready to place it my FPS/UPS takes a massive hit. It seems the slow down is caused under "Game Render Preparation".
The map otherwise works at 60/60.
I know large blueprints cause performance problems however I thought I'd post this one in particular because for whatever reason it seems to absolutely nuke FPS/UPS compared to other ones. I obviously have no idea how this is all done and whether it's based off the entity count or not but I can blueprint builds that have 3-4 times the number of entities without such a performance drop. Perhaps it's something to do with the storage chest entity or something?Rseding91 wrote:That part of the logic is actually minimal. It's the copying of the blueprint in hand, adjusting it to the correct world position, rotating every entity, setting each entity up, and then destroying each one after it's rendered that takes the majority of the time.mrvn wrote:Blueprints have to check every entity to see if there is something beneath it that conflicts or needs to be deconstructed (with shift pressed). It can probably be optimized (e.g. pre-compute a single mask where trees need to be deconstructed instead of checking per entity) but as is a render slowdown isn't surprising.Xeteth wrote:Found something new that absolutely tanked my FPS/UPS today.
I am making a 'Coal Bunker' which has a ton of storage chests - when I hold the blueprint in hand ready to place it my FPS/UPS takes a massive hit. It seems the slow down is caused under "Game Render Preparation".
The map otherwise works at 60/60.
Patch notes 0.19:Core count means nothing. It's limited by RAM latency which is limited by the speed of light and the distance between the CPU and RAM sticks on motherboards.
Only 180%? Man, the devs must be starting to get lazy.bobucles wrote:Patch notes 0.19:Core count means nothing. It's limited by RAM latency which is limited by the speed of light and the distance between the CPU and RAM sticks on motherboards.
- The speed of light was causing a lot of performance issues but we found a workaround to increase it 180%.
Light is slowed down by gravity and you can make your CPU only have so much lighter with helium cooling.Jap2.0 wrote:Only 180%? Man, the devs must be starting to get lazy.bobucles wrote:Patch notes 0.19:Core count means nothing. It's limited by RAM latency which is limited by the speed of light and the distance between the CPU and RAM sticks on motherboards.
- The speed of light was causing a lot of performance issues but we found a workaround to increase it 180%.
Or you can use quantum entanglement on the cpu and the ram to have no delay in the communication, and then have infinite speedup and not worry about optimations ever again...mrvn wrote:Light is slowed down by gravity and you can make your CPU only have so much lighter with helium cooling.Jap2.0 wrote:Only 180%? Man, the devs must be starting to get lazy.bobucles wrote:Patch notes 0.19:Core count means nothing. It's limited by RAM latency which is limited by the speed of light and the distance between the CPU and RAM sticks on motherboards.
- The speed of light was causing a lot of performance issues but we found a workaround to increase it 180%.
