That’s Too Slow, Optimize It!
Optimizing A Piece Of Code — Java
Different Insights On How To Increase Code Performance
Have you been coding non-stop everyday again?
ave you ever wondered if your code is “fast” enough to impress someone?
Or have you ever wondered:
Can My Code Just Go Blazing Fast Already?
— Probably You Done With~Uh… Coding?
1 — Be The Perfectionist That Sees Their Work Like It’s Somebody Else’s
Yes, I did personally designed this meme-like template lmao.
This is a pretty-much oversimplified example of judging your own work.
- Judge your work like a menacing beast in the UX department.
- You won’t be able to optimize your code if you think that it is “fast”.
- You won’t be able to see the sloth in your code otherwise.
This is an important mindset before you start optimizing your code.
2 — Limit The Number Of Instructions Being Sent To The JVM
Did you understand a thing or a single word above?
I bet your CPU recognizes all the words that can be seen above.
Think that your the CPU being bombarded by instructions here and there.
- Lesser instructions mean less to do.
- Lesser instructions mean less overhead.
- Lesser instructions mean more room for a performance boost.
Let’s do a pretty quick example.
What option would you pick?
Option 1:
- Automatically creates a
StringBuilder
withnum
as a constructor argument. - That calls
Object#toString()
. - After that it appends the empty string
""
. - Lastly, it calls
#toString()
.
Option 2:
- Calls
String.valueOf()
withnum
as an argument.
Option 3:
- Straight up assign
"1000"
as a String since the value is final anyway.
Option 4:
- The chad just doesn’t create the
num
variable at all and straight up assignsstr
as a final String literal ressembling"1000"
.
The Observation:
- Option 1 is for monkey-typing but it’s slow anyways.
- Option 2 is straight up 1 method and its overhead.
- Option 3 is straight up just assign the variable.
- Option 4 is straight up yeet a variable and just take what’s needed.
Option 4 is most likely the fastest since it has the least instructions possible.
BUT in the real world, Option 2 is viable since num
might not be a constant.
3 —Choosing The Right I/O Stance
The buffer, Git-it? No? You don’t? Nevermind.
There are mostly two stances in the I/O world:
1— The buffered I/O reader.
- Transfers data to a temporary location first (overhead).
- Reading after buffering repeatedly might be faster.
2 — The non-buffered I/O reader.
- Reads the data directly from it’s source (pretty fast).
- Reading repeatedly might get slower over time (I/O limitations).
In other words:
- Buffered for fast repeated reading from an unmodified source.
- Non-buffered for fast reading from a constantly modified source.
- Uga booga.
4 — Stop Overly Complicating Things
Imaging building an engine (we’re programmers, not mechanics).
Instead of just attaching a motor and seeing your car fly…
…You build an overly complicated contraption that doesn’t work anyway.
Remember no. 2? This is literally just a sequal to that.
Yuck, 4 space tab indenting.
You can tell that someone’s not gonna be impressed by the performance overhead overhaul you just did back there.
5— Stop Setting Variables To Their Default Values
Imagine setting a varaible by it’s default value…
…It’s like you never read no. 2 at all.
The primitives byte
, short
, int
and long
all share the same default of 0
.
While the primitive char
resorts to the code-point null
/ \u0000
/ \000
.
While Object
s like the String
or MappedByteBuffer
defaults to null
.
It will be a literal waste of time, compiler optimized or not.
There are a lot more that you can do to try and optimize your code…
…But I’ll have to end this over here so… Go! Go! Go! Code it out!
Want to see me procrastinate but most importantly code?
Go and find out if you’d like My YouTube Channel then!
Want to read another article?
Read — Regex-Patterns-Made-Easy— by yours truly.