Hacker News Reader

Comment by macromaniac | Hacker News Reader

>I'd tweak the script; then to see the results I would press F5 to run the already built binary and wait over a second EVERY SINGLE TIME (about 1480ms).

I put in a bug report for this years ago but it got ignored :( https://github.com/microsoft/vscode/issues/137066

Vscode has gotten slower over time. It's true you can't get nanosecond performance out of JS, but anything under 17ms should be trivial. I believe the vscode developers are skilled, it's just they don't care (imo) enough about performance for whatever reason, and that's a shame.

View on HN

Everybody who worked writing code in the 70s-90s is smirking at “wait over a second”.

Back in the day, I used to go get my coffee, shoot the shit in the break room for a few minute, and come back to find my debug runs just starting.

Turbo Pascal was so fast in the 80s that if I saw a syntax error further down the page it was faster to hit "compile" and let the compiler move the cursor to the error than it was for me to move the cursor myself.

It was a very special compiler and they don't make them like that anymore.

The trick is to have language "optimized for compilation" and do not do fancy optimizations.

Java is similar (but overall infrastructure around compiler makes it slow).

Golang also quite fast.

I think LLVM missed the boat, on this, by being an early mover. A lot of the optimizations are resource-only analyses; the few that re not are "just" various levels of interpretation. That kind of implies we need a framework to define resource utilization and evaluation at the instruction/machine-code level with a standard API. Having an optimizer for an abstract IR is less useful.

The point being that compilers would then target emitting reasonable machine code at speed, and The Real LLVM would do analysis/transform on the machine code.

The tricks in the 80s were different than today's tricks.

(1) Single-pass compiler. No separate pass to convert to object or executable.

(2) Written in assembler (!). Helps that Pascal has fewer dark corners.

(3) No use of disk. A single file read or write would take 10-20s on a floppy. Instead, it's memory to memory.

It’s crazy that this is still the gold standard

We got outsteped by C and C++ industry adoption, followed by doing everything in interpreted languages.

Finally 30 years later, the pendulum is turning around.

And V 3.01 was under 40 KB (not a typo), and included a basic WordStar editor clone for program editing!

They still do. Lua is likewise extremely fast, and comes without bullshit mostly,

And in the 00's things were pretty instantaneous, at least from a UI perspective. I actually developed some "bad" habits where I'd just hold the step hotkey down to advance my program when debugging. And everything just worked and was synchronous. All the registers updated with each step, as well as my watched variables and everything else I can think of. I'm pretty sure this was visual studio 6.

That was peak Microsoft debugging experience for me, everything after that was worse, admittedly I did drop it and moved to Linux, so maybe it is good now. Although I very strongly doubt it.

This is the reason I like VIM. While I’m mostly using it locally, this deterministic way of handling input means that I can edit over a slow ssh connection faster than the result being displayed. The VIM language is like playing music, you’re only conscious of mistakes.

There was a data entry program (I forget its name) that I liked too. I could enter a complete survey form without watching the screen, just by tab-ing. I memorized the sequences and shortcuts for dropdown. Made a dull job less frustrating.

Amazing how technology has improved and matured in 50 years…

Wasn't that mostly compiling though? VSCode's CMake tools take multiple seconds just starting an already-built executable.

In my experience, that one-second wait to run a binary that you just built is due to realtime scanning by Windows Security. It's not very bright. It sees a new .exe file and assumes you downloaded it from the Pirate Bay, even though it was written by link.exe.

You can disable it as long as Group Policy doesn't dictate otherwise.

Not having an exclusion for a development directory is like using a 10yo machine or using a laptop without the power brick connected: it’s basically leaving half the perf on the table.

Still, a second seems a bit much for a real-time scan.

Under Windows 11, a "dev drive" can also make a big difference.

https://learn.microsoft.com/en-us/windows/dev-drive/

Thanks for tip, TIL

Clearly you do not work for corporate America. Any amount of performance loss is acceptable to check a security compliance checkbox somewhere.

This is the number 1 reason to use macbooks instead of windows laptops at any job. Security compliance software is like a cancer on windows, macos has some of this kind of crap as well but is nowhere near as bad.

I work for a large, slow moving US company in traditional industry. Of course there is an exclusion list, and it contains a few commonly used dirs like “C:\dev” and so on. If that would change (or if the request years back to have company wide exclusions wouldn’t have been listened to), it’s the kind of thing I’d insta-quit a job over, even after 20 years.

So anecdotally (N=1) it’s not automatically horrible in US orgs.

Don't forget the enterprise market has a whole different threat model. Even though blanket exclusions are often used, a determined attacker will quickly figure out to dump their remote exploration tool in c:\dev .

If the attacker gets far enough to be able to put something in c:\dev and run it, your protections have already failed.

I'm on linux tho (and the author of the article)

Wow, marked as-designed. I guess that's one way to fix the issue. In my experience latency needs to be < 250ms to be considered good, 500ms is roughly the max people can put up with, 2s is enough to drive people insane.

Reply on news.ycombinator.com