While "handmade" code may be faster, it's also a big time sink and as a developer your job is to make tradeoffs.
For most software, you should probably focus on architecture instead of the lower level of your code. Sane code and architecture solves most performance issues. This includes technology decisions, like using web tech for applications instead of the native platform.
For example, Apple has had a lead of at least five years over Android when it comes to performance and user experience, because their system and apps were all built in native environments, instead of the JVM abstraction layer. It took at least five years for Android to catch up, and it took quadcore CPU's to do it. Around then, Apple carefully started using dual-core CPUs.
Meanwhile, companies like Facebook and Twitter spent dozens of work-years on trying to make web technology feasible in native apps and never really cracked it.
If they had just focused on building good native apps they wouldn't have wasted so much time.
Caveat / Aside: IIRC Facebook is having / has had massive issues with having too much code / classes / files in their app(s), on both iOS and Android. Which is (I believe) one of the reasons why they split off Messenger into its own app at the time.
Here's the fundamental difference between iOS and Android, and it's related to memory management:
On iOS, you pay for memory management in small installments, which make your code slower overall (reference counting in ObjC/Swift), but predictably so.
On Android, you pay almost nothing for memory management until at some random point the garbage collector shows up and stops your program to clean up your mess. Your program is going to be janky.
Apple deliberately ships devices with little RAM and kills applications that use too much of it. As a developer you better pay attention, or you will be flooded with bad reviews.
Google leaves RAM up to vendors. The secret to good performance with GC is to make the heap twice as large as the data which it contains. Low-end Android devices feel low-end, not just because of slower CPUs, but also because of too little RAM.
It has nothing to do with the "JVM abstraction layer". Java code on a good JIT easily runs faster than Swift or ObjC if there's a lot of allocations involved, but the GC behavior must be accounted for to give a good experience.
For most software, you should probably focus on architecture instead of the lower level of your code. Sane code and architecture solves most performance issues. This includes technology decisions, like using web tech for applications instead of the native platform.
For example, Apple has had a lead of at least five years over Android when it comes to performance and user experience, because their system and apps were all built in native environments, instead of the JVM abstraction layer. It took at least five years for Android to catch up, and it took quadcore CPU's to do it. Around then, Apple carefully started using dual-core CPUs.
Meanwhile, companies like Facebook and Twitter spent dozens of work-years on trying to make web technology feasible in native apps and never really cracked it.
If they had just focused on building good native apps they wouldn't have wasted so much time.
Caveat / Aside: IIRC Facebook is having / has had massive issues with having too much code / classes / files in their app(s), on both iOS and Android. Which is (I believe) one of the reasons why they split off Messenger into its own app at the time.