31–40 of 62 posts
There is something about this site that absolutely destroys Firefox when scrolling. Expensive work in a scroll handler isn't good guys :(
Earlier quoted context omitted.
I would not be too quick to blame the authors of the website. It seems likely to be the same Firefox bug as all the other cases of HN comments complaining about bad scrolling performance in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1250947
Bad link, I'm afraid... It's about a box-shadow glitch.
Earlier quoted context omitted.
Bad link, I'm afraid... It's about a box-shadow glitch.
It's the correct link (if you read the last 15 or so comments, it'll be more obvious that there is a performance component to the issue).
.widewrapper.main {
box-shadow: inset 1px 3px 1px -2px #ababab;
}It's interesting how most of the optimizations are only really available if you essentially write your programs in a functional style. That is, they all depend on the compiler being able to analyse the local scope to decide whether the state changes are confined enough that it can perform an optimization without changing behavior. If a reference escapes, even into a private, instance variable, the compiler will (admi…
Escape analysis is pretty damn capable if you can give it enough time to run.
Earlier quoted context omitted.
Escape analysis is pretty damn capable if you can give it enough time to run.
The analysis is fine, but "escape analysis" is often conflated with stack allocation, and at this hotspot is actually really terrible. The constraints on allocating to the stack mean it happens very infrequently, even if the literal escape analysis would permit it otherwise.
But I don't think the constraints are that bad are they? Can you give examples? Modern compilers like Graal can even scalar replace objects if they will escape in the future.
Earlier quoted context omitted.
The analysis is fine, but "escape analysis" is often conflated with stack allocation, and at this hotspot is actually really terrible. The constraints on allocating to the stack mean it happens very infrequently, even if the literal escape analysis would permit it otherwise.
Calling it 'stack allocation' is confusing - object fields are replaced with scalars in the IR. The whole object is not allocated as it would have been on the heap but on the stack in the alloca sense. But I don't think the constraints are that bad are they? Can you give examples? Modern compilers like Graal can even scalar replace objects if they will escape in the future.
The biggest constraint by far is the reliance on inlining. Inter-procedural escape analysis could potentially remove the need for value types in many places, but it doesn't seem like the JVM engineers believe that's feasible.
Earlier quoted context omitted.
Ah, the Java is slow argument. When were you doing Enterprise Java? It must have been around the pre HotSpot years. As for applications that are huge, memory hogs, complex and non elegant, well, congratulations you just described the majority of enterprise applications.
Not pre-HotSpot; I saw the release of HotSpot, and while it did improve performance considerably compared to before, it was still pretty bad compared to native. I see the proliferation of "Java is not slow" articles as a sign that it is --- if it wasn't, why would there be a need for such strong propaganda and carefully constructed microbenchmarks? Sun/Oracle have a deep interest in hiding their "naked emperor". Wher…
Nobody writes "C is not slow" articles any more, but I remember a time when there were people who believed C++ was inherently slower than C. Maybe some such people still exist! I don't see much talk like that anymore though.
With respect to bloated code, the 1990's and early 2000's also saw things like DCOM and other C++ bloat-zones. It's not really to do with the language. The presence of bloat in enterprise apps is more to do with the lack of competition (bespoke apps are by definition monopolies), the frequent lack of deadline pressure (deadlines are invariably artificial) and the inflexible team sizes (over-engineering is incentivised by the need to retain a nice safe corporate job). The fact that enterprise software and Java go hand in hand speaks more to the lack of competition in the space Java plays in, than anything about the language itself.
Maybe a noob observation, but can anyone explain why the Lock Coarsening example is valid? Seems to me that locks on A with a lock on B in between is not equivalent to 2 locks on A and then one on B... Unless the programmer made a cognitive error the cases seem incomparable, unlike the other examples.
"Seems to me that locks on A with a lock on B in between is not equivalent to 2 locks on A and then one on B" You're looking at: public void canNotBeMerged() The locks can't be merged.
Earlier quoted context omitted.
Calling it 'stack allocation' is confusing - object fields are replaced with scalars in the IR. The whole object is not allocated as it would have been on the heap but on the stack in the alloca sense. But I don't think the constraints are that bad are they? Can you give examples? Modern compilers like Graal can even scalar replace objects if they will escape in the future.
Given that the HotSpot compilers are not Graal and HotSpot's scalar replacement optimisation is notoriously fragile, I think the original statement was fair. Once Java 9 rolls around and Graal is just a plugin instead of a whole separate VM build, it'll be less fair, and if Graal ever becomes the default compiler that replaces C2 then it'll be even more fair, but I guess that is years away at best. The biggest constr…
Earlier quoted context omitted.
"Seems to me that locks on A with a lock on B in between is not equivalent to 2 locks on A and then one on B" You're looking at: public void canNotBeMerged() The locks can't be merged.
Yeah, but the semantics there refer to merged by an optimization? What's the point of having incomparable examples?