> Why do I have to provide it? The burden is the other way around.
Well, it sounds like you have an axe to grind, but I didn’t ask to “prove” anything; I was curious to learn what was meant by the bad-performance claim. I don’t program in any of these technologies; I don’t have a horse in this race.
Let’s try this again:
> Blazor's architectural model makes it impossible to be "performant."
.NET perf can be great in the sense that it provides more tools to write C-like code while still taking advantage of safe memory management, as compared to Java. On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM.
Why, for instance, does the CLR GC not have something like TLABs? The result is that it seems like .NET devs have to worry a lot more about the expense of small, short-lived allocations, while in Java these things are much cheaper.
Overall, I think it's easier to program idiomatically in Java and get decent performance out-of-the-box, while C# may provide more opportunities for optimization without having to rely on something equivalent to sun.misc.Unsafe and offheap allocations.
And it does, how I wish for Valhala to become a reality, and finally having structs, spans, and all the other C++ like capabilities C# enjoys, and Java lacks.
> On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM
I've always heard this, but does it actually manifest in noticeably worse performance than the JVM? Go has a much simpler GC, but it's not terribly slower than Java (I do know they are optimized for different things).
It seems like C# is within bounds of Java while also having great performance escape hatches.
Say more?
Why does his statement not require more substance? Why do I have to provide it? The burden is the other way around.
Blazor's architectural model makes it impossible to be "performant." It's not even debatable.
What you gain in DevEx you lose substantially in user experience.
> Why do I have to provide it? The burden is the other way around.
Well, it sounds like you have an axe to grind, but I didn’t ask to “prove” anything; I was curious to learn what was meant by the bad-performance claim. I don’t program in any of these technologies; I don’t have a horse in this race.
Let’s try this again:
> Blazor's architectural model makes it impossible to be "performant."
Say more?
1 reply →
I'm speaking of static server-side components, thus no JS or WASM. Wouldn't touch any other Blazor mode for a public facing app.
1 reply →
.NET perf can be great in the sense that it provides more tools to write C-like code while still taking advantage of safe memory management, as compared to Java. On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM.
Why, for instance, does the CLR GC not have something like TLABs? The result is that it seems like .NET devs have to worry a lot more about the expense of small, short-lived allocations, while in Java these things are much cheaper.
Overall, I think it's easier to program idiomatically in Java and get decent performance out-of-the-box, while C# may provide more opportunities for optimization without having to rely on something equivalent to sun.misc.Unsafe and offheap allocations.
And it does, how I wish for Valhala to become a reality, and finally having structs, spans, and all the other C++ like capabilities C# enjoys, and Java lacks.
> On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM
I've always heard this, but does it actually manifest in noticeably worse performance than the JVM? Go has a much simpler GC, but it's not terribly slower than Java (I do know they are optimized for different things).
It seems like C# is within bounds of Java while also having great performance escape hatches.