7 ms·

>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

>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 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.

croes 2y ago
[flagged]
- cdaringe 2y ago
  My experience on their issue tracker is, if i give thoughtful input i get thoughtful responses. Ive had multiple issues and features acted on. YMMV i suppose.
  - croes 2y ago
    But how many of that input should have been from internal testing instead of users after the rollout?
    - alanjay 2y ago
      Microsoft don't have internal testing. They get the devs, who already know the code, to see if it makes sense. And woe betide you if you disagree with the PM!
      - croes 2y ago
        That's my point, they outsourced their testing to the customer. That's a no-go.
- chucky 2y ago
  What is that even supposed to mean?
  - croes 2y ago
    That MS only reacts if it hurts their profits
kcplate 2y ago
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.
- blegr 2y ago
  Wasn't that mostly compiling though? VSCode's CMake tools take multiple seconds just starting an already-built executable.
- cjensen 2y ago
  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.
  - outside1234 2y ago
    It’s crazy that this is still the gold standard
    - pjmlp 2y ago
      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.
  - vbezhenar 2y ago
    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.
    - thechao 2y ago
      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.
cjbgkagh 2y ago
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.
CamperBob2 2y ago
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.
- alkonaut 2y ago
  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.
  - 0cf8612b2e1e 2y ago
    Clearly you do not work for corporate America. Any amount of performance loss is acceptable to check a security compliance checkbox somewhere.
    - alkonaut 2y ago
      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.
    - wkat4242 2y ago
      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 .
      - josephcsible 2y ago
        If the attacker gets far enough to be able to put something in c:\dev and run it, your protections have already failed.
deleted 2y ago
[deleted]

croes 2y ago

[flagged]

cdaringe 2y ago
My experience on their issue tracker is, if i give thoughtful input i get thoughtful responses. Ive had multiple issues and features acted on. YMMV i suppose.
- croes 2y ago
  But how many of that input should have been from internal testing instead of users after the rollout?
  - alanjay 2y ago
    Microsoft don't have internal testing. They get the devs, who already know the code, to see if it makes sense. And woe betide you if you disagree with the PM!
    - croes 2y ago
      That's my point, they outsourced their testing to the customer. That's a no-go.
chucky 2y ago
What is that even supposed to mean?
- croes 2y ago
  That MS only reacts if it hurts their profits

kcplate 2y ago

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.

blegr 2y ago
Wasn't that mostly compiling though? VSCode's CMake tools take multiple seconds just starting an already-built executable.
cjensen 2y ago
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.
- outside1234 2y ago
  It’s crazy that this is still the gold standard
  - pjmlp 2y ago
    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.
- vbezhenar 2y ago
  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.
  - thechao 2y ago
    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.

cjbgkagh 2y ago

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.

CamperBob2 2y ago

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.

alkonaut 2y ago
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.
- 0cf8612b2e1e 2y ago
  Clearly you do not work for corporate America. Any amount of performance loss is acceptable to check a security compliance checkbox somewhere.
  - alkonaut 2y ago
    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.
  - wkat4242 2y ago
    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 .
    - josephcsible 2y ago
      If the attacker gets far enough to be able to put something in c:\dev and run it, your protections have already failed.

deleted 2y ago

[deleted]