Change findblocks into promise have a sense? #3218
Conversation
|
Also, yielding to the event loop inside of any hot/iterative code is really bad as that prevents any JIT optimizations, on top of the event loop overhead (copying memory, waiting, etc). If it's really necessary to split up work, you would need to find a better algorithm to segment the data and yield as little as possible (maybe a few times depending on search area) to make it optimal. I think a better solution would be to profile the existing code and see if synchronous optimizations could be made (reducing copies, type conversions, checks, etc). As of right now, it seems findBlock() is running through every block in the box, when it could be exiting early on the first match. That's an easy optimization. |
|
I don't think it can help much in optimizing the code, I don't understand it very well, and when I want to see the variable types I see that many of them are not complete.
If you want I can make a new method "searchBlock" & "searchBlocks" that use a common code or most of it |
It will, pushing things to do later will make things slower, not faster. It will still block your program, including timers. The only way to not block aside a worker is to do less operations or more efficient ones.
Use control + f to search the codebase, it's not very big or complicated code, everything is defined in a few lib/plugins files.
Echo my previous comment: As of right now, it seems findBlock() is running through every block in the box, when it could be exiting early on the first match. That's an easy optimization. |
|
I'm on it =)
Yes and not, yes is more slower, but the bot dosent freeze on to do this operation, (of course this affect to the rest of bot while are executing ) anyways i try to see if it can also be improved without promises |
|
Possibly related to #3216. |
One of the best ways to make things faster is by minimizing memory allocations/copies, especially in hot code. Simplifying the code helps, but be cautious here since less code doesn't mean faster, if that "less code" is just an abstraction for really complex code under the hood. PrismarineJS/prismarine-physics@d29774a is a good example for that, as lots of garbage from temporary objects would be created in hot code. Also, moving the world data and these findBlock methods to prismarine-world per #334 would make it easier to remove where the bottlenecks are in the current code. |
|
ci is failing |
|
I tried to improve the optimization but without results.. Finally are you interested to merge this pr? |
|
yeah actually reading the previous discussion it seems this PR is not really helping right? maybe we should just close it? |
|
There are contrary opinions, I think so, but I do not have the knowledge to improve performance, if perhaps it is not interesting we can close the pr |
|
ok |
Hi guys, I have been noticed that my bot sometimes freezes, I have detected that if I run findblock to search in a large radius, this causes that the bot freeze until the search is finished,
I think it would be a good idea change the method to a promise, and give it a short wait for the bot to exchange the action processes with the search and this not freeze the bot,
The change is simple, which will cause users to have to adapt their code to a promise
Obviously the performance is worse; the same test for "normal"/"promise" is 3-4 times slower,
What this slowness in my opinion compensates for the bot being much "fresher" in these actions without blocking,
The important code are only in block.js
Change findblocks into promise have a sense?