o my. hello there.
I'll put on my serious face for this.
Before getting into the more active quote/explanation back-and-forth that usually emerges from this, I want to clarify two things that seem to generally apply to a lot of your comments: first, that there's a lot of stuff I've worked on that is very much reborn-specific and I fully realize that it won't apply for a starter-kit meant to apply for all fan games; second, we're also running on an older version of essentials, and I'll clarify whether what I've worked on is in the newer version or not. Regardless, none of this is meant to be a personal attack on you or anyone else involved in the development of the engine itself- if this eases some of the hostility at all.
Anyway, into the nitty-gritty.
This is going to require some additional clarification.
After some later probing at the system, it appears that this was not the primary source of the issues I was seeing. The real issue was PBMoveData.new. I'll consider your comments towards dexdata to be effectively the same as what you may say towards this, as the two functions work very similarly.
You may say that cutting the number of abilities read by 3 is insignificant. In many cases, I would agree. Inefficiencies of that sort are so minor as to not be worth fixing. However, my assumption going into this fix was that this function was called a lot. Our data showed that we had 5250 calls to hasWorkingAbility and I had (wrongly) assumed that every call corresponded with a call to the ability function. Had that been the case, the decrease in CPU load caused by this would've been substantially greater.
The real culprit, PBMoveData.new, instead does... 11 string reads? each time it's called. And it ends up taking a significant amount of times to process this. Changing this function lead to a noticeable speedup during AI processing.
So, sure, if the function was called once, I'd agree. And, in general, fixing some minor math functions is not the focus of what our optimizations have been about.
I mentioned them because I find them irritating.
It really puts the cherry on top of the "why is this here" feeling that I often have while working in the code. It certainly doesn't help that there's a noticeable lack of comments.
I also can't help but notice there's more of this in 17.2's in_range function.
But this isn't quite how interpretive languages work. Nor is it quite how CPUs work. Pure machine code instruction for multiplication can take 1-4 cycles depending on number size. Division takes at least 10. This is further complicated depending on how exactly Ruby decides to send the instructions in the first place (which, considering we run 1.8, is likely not done very well). This is a bit more of a technical gripe, but the point I'm trying to make is that this isn't quite as clear-cut as you may want it to be.
In our version, this was set as a specific number and never changed (aside from a random dungeon generator that, I believe, doesn't work), which thus incurred the same ire as normal excessive multiplication.
So, I say this about the profiler a lot, but it's probably worth repeating again since I'm sure a lot of this was specifically on the dev server:
It was designed for RMVXA which has a much faster version of ruby. It adds a shitload of overhead to every function, and the ms/call readouts that it produces need to be taken with a grain of salt.
That said, some of this seems... mildly insulting?
No? That would be dishonest?
I'm not here to flex on essentials or some bullshit. I'm here because people regularly complain about the performance. It has been a thorn in my side for a very long time. Lying about improvements does no one any good. If you'd like to see some actual evidence of improvements, I have a lot of it. Perhaps it would be worth making a devblog post to better document this.
I feel like this highlights a pretty fundamental difference between how you and I view this problem. You're here for the engine, I'm here for the game. If these performance issues are fake, as you imply, then why am I seeing improvements?
Firstly, as, well, self defense, this is a devblog post for the game, not the engine. I write with a very informal style that people seem to find entertaining. The optimizations I've discussed are not exhaustive, they do not represent everything I've worked on, they are specifically chosen because of the blend of information/enjoyment value I feel they offer the reader. If you read the optimization posts and think there's a lot of memes in there....that's the point. If you think that is all I do, then, well, that's insulting.
I... look, I don't want to break this down here, because overall it seems like this is just a knee-jerk reaction to a series of posts that disparage essentials. And, like, I understand that.
But I feel like there's a disconnect here between what you're talking about and what's really happening.
I'll put my money where my mouth is.
I implemented three changes into Desolation: the needs_update variable for events; the updated in-range? function; and the new controls checker.
50% improvement in FPS on the overworld.
If you still doubt me, I can personally show you what I did as I did it. We can use vanilla scripts and everything.
But I also really don't think that it's worth fighting this out.
I'd like to call a truce on this and, perhaps, work on making the next release of essentials more efficient.
We can backport some other improvements to our version and push some improvements to yours.