upvote

points

by nananana95 hours ago |
comments
upvoteby groundzeros20155 hours ago|
[-]
1. Why can’t we have better green threads implementations with better scheduling models?

2. Unchecked array operations are a lot faster. Manual memory management is a lot faster. Shared memory is a lot faster.

Usually when you see someone reach for sharp and less expressive tools it’s justified by a hot code path. But here we jump immediately to the perf hack?

3. How many simultaneous async operations does your program have?

reply
upvoteby vlovich1234 hours ago|
parent|
[-]
Well, if you offload heavy compute into an async task, then usually it depends strictly on how many concurrent inputs you are given. But even something as “simple” as a performance editor benefits from this if done well - that’s why JS text editors have reasonably acceptable performance whereas Java IDEs always struggled (historically anyway since even Java has adopted green threads).
reply
upvoteby ptx4 hours ago|
parent|
next
[-]
Are you sure Java's UI issues are caused by threading and not just Swing being a glitchy pile of junk?

For example, if you don't explicitly call the java.awt.Toolkit.sync() method after updating the UI state (which according to the docs "is useful for animation"), Swing will in my experience introduce seemingly random delays and UI lag because it just doesn't bother sending the UI updates to the window system.

reply
upvoteby groundzeros20154 hours ago|
parent|
prev|
next
[-]
You think IDEs are written in JS because of the performance benefits of the threading model?

I thought it was because they could copy chromium.

reply
upvoteby vlovich1234 hours ago|
parent|
[-]
Why do you think they don’t struggle with input latency? Because the non blocking nature built into the browser model is so powerful and you cannot get that with threads.
reply
upvoteby groundzeros20154 hours ago|
parent|
next
[-]
I disagree with the premise. I cannot imagine a better latency experience than blocking loop IDEs like VS6.

Which inputs are getting latency? The keyboard? The files?

> the non blocking nature

https://youtu.be/bzkRVzciAZg?si=BuBXxHTgN0OqsAhI

reply
upvoteby usrnm4 hours ago|
parent|
prev|
[-]
Are you sure that latency-sensitive parts are written in async JS instead of having a separate UI thread (pool)? I have no idea myself, but without knowing the details it's hard to argue. Note, that browsers themselves, are usually written in languages like C++ or Rust. They run JS, but aren't written in it
reply
upvoteby pjmlp2 hours ago|
parent|
next
[-]
Yes they are, the UI layer is mostly JS, outside the rendering and layout engines.
reply
upvoteby spwa43 hours ago|
parent|
prev|
[-]
If you implement threads and code that reacts to an input queue (e.g. PostMessage, queue_push, mq_send, ...), you've implemented (probably a bad version of) async threads. And yes, that's exactly what Windows 1.0 did and what made it great.

But God help you if you have to change the code. Async threads are a way to organize it and make it workable for humans.

reply
upvoteby PunchyHamster3 hours ago|
parent|
prev|
next
[-]
Maybe you remember performance of IDEs from 15 years ago because that definitely isn't my experience.
reply
upvoteby jcelerier1 hours ago|
parent|
prev|
[-]
> that’s why JS text editors have reasonably acceptable performance

Absolutely not

reply