The autoboxing in a loop case can be handled by the compiler.
Java is fast, code might not be
71–80 of 259 posts
Re: Java is fast, code might not be
#72Understanding algorithmic complexity (in particular, avoiding rework in loops), is useful in any language, and is sage advice. In practice though, for most enterprise web services, a lot of real world performance comes down to how efficiently you are calling external services (including the database). Just converting a loop of queries into bulk ones can help loads (and then tweaking the query to make good use of inde…
Easy to get wrong as well.
There's a balance with a DB. Doing 1 or 2 row queries 1000 times is obviously inefficient, but making a 1M row query can have it's own set of problems all the same (even if you need that 1M).
It'll depend on the hardware, but you really want to make sure that anything you do with a DB allows for other instances of your application a chance to also interact with the DB. Nothing worse than finding out the 2 row insert is being blocked by a million row read for 20 seconds.
There's also a question of when you should and shouldn't join data. It's not always a black and white "just let the DB handle it". Sometimes the better route to go down is to make 2 queries rather than joining, particularly if it's something where the main table pulls in 1000 rows with only 10 unique rows pulled from the subtable. Of course, this all depends on how wide these things are as well.
But 100% agree, ORMs are the worst way to handle all these things. They very rarely do the right thing out of the box and to make them fast you ultimately end up needing to comprehend the SQL they are emitting in the first place and potentially you end up writing custom SQL anyways.
Re: Java is fast, code might not be
#73When you're using a programming language that naturally steers you to write slow code you can't only blame the programmer. I was listening to someone say they write fast code in Java by avoiding allocations with a PoolAllocator that would "cache" small objects with poolAllocator.alloc(), poolAllocator.release(). So just manual memory management with extra steps. At that point why not use a better language for the tas…
You might have an application for which speed is not important most of the time.
Only one or two processes might require allocation-free code. For such a case, why would you burden all of the other code with the additional complexity?
Calling out to a different language then may come with baggage you'd rather avoid.
A project might also grow into these requirements. I can easily imagine that something wasn't problematic for a long time but suddenly emerged as an issue over time. At that point you wouldn't want to migrate the whole codebase to a better language anymore.
Re: Java is fast, code might not be
#74The Autoboxing example imo is a case of "Java isn't so fast". Why can't this be optimized behind the scenes by the compiler ?
Rest of advice is great: things compilers can't really catch but a good code reviewer should point out.
Re: Java is fast, code might not be
#75Nitpick just because.
Orders by hour could be made faster. The issue with it is it's using a map when an array works both faster and just fine.
On top of that, the map boxes the "hour" which is undesirable.
This is how I'd write it
long[] ordersByHour = new long[24];
var deafultTimezone = ZoneId.systemDefault();
for (Order order : orders) {
int hour = order.timestamp().atZone(deafultTimezone).getHour();
ordersByHour[hour]++;
}
It's also not less readable, just less familiar as Java devs don't tend to use arrays that much.
Re: Java is fast, code might not be
#76The Autoboxing example imo is a case of "Java isn't so fast". Why can't this be optimized behind the scenes by the compiler ? Rest of advice is great: things compilers can't really catch but a good code reviewer should point out.
Why should compiler optimize obviously dumb code? If developer wants to create billions of heap objects, compiler should respect him. Optimizing dumb code is what made C++ unbearable. When you write one code and compilers generates completely different code.
Re: Java is fast, code might not be
#77First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup. I wish Java had a proper compiler.
You can create a native executable with GraalVM. Alternatively, if you want to keep the JVM: With the ongoing project Leyden, you can already "pre-train" some parts of the JVM warm-up, with full AoT code compilation coming some time in the future.
GraalVM has a lot of limitations, some popular lib don't work with it. From what I remember anything using reflection is painful to use.
Re: Java is fast, code might not be
#78When you're using a programming language that naturally steers you to write slow code you can't only blame the programmer. I was listening to someone say they write fast code in Java by avoiding allocations with a PoolAllocator that would "cache" small objects with poolAllocator.alloc(), poolAllocator.release(). So just manual memory management with extra steps. At that point why not use a better language for the tas…
Bad idea. I've made a pool allocator before, but that was for expensive network objects and expensive objects dealing with JNI.
Doing it to avoid memory pressure generally means you simply have a bad algorithm that needs to be tweaked. It's very rarely the right solution.
Re: Java is fast, code might not be
#79First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup. I wish Java had a proper compiler.
You can create a native executable with GraalVM. Alternatively, if you want to keep the JVM: With the ongoing project Leyden, you can already "pre-train" some parts of the JVM warm-up, with full AoT code compilation coming some time in the future.
GraalVM is terrible. Eats gigabytes of memory to compile super simple application. Spends minutes doing that. If you need compiled native app, just use Golang.
Re: Java is fast, code might not be
#80Any non-trivial program that has never had an optimizer run on it has a minimal-effort 50+% speedup in it.