141–150 of 429 posts
I understand that different people have different skill sets, that's totally fine. I don't think every single senior developer at Microsoft should have the skillset to fix performance issues like this. That said, however, I do think developers should be able to recognize when a task requires a skill that they do not have. In those cases it's best to reach out to someone within the organization who has that skill. Or,…
A few hours later another programmer came up with the prototype of a much faster terminal renderer, proving that for an experienced programmer a terminal renderer is a fun weekend project and far away from being a multiyear long research undertaking. I have no idea if this is the case here, and I suspect it might not be, but pretty much every time I've seen a developer complain that something is slow and then 'prove'…
I am writing this application that displays the file system in the browser in a GUI much like Windows Explorer or OSX Finder. It performs file system search substantially faster than Windows Explorer. Windows Explorer is written in a lower level language with decades of usage and experience where my application is a one man hobby project written in JavaScript (TypeScript).
The reason why the hobby project is so substantially faster than a piece of core technology of the flagship product of Microsoft is that it does less.
First, you have to understand how recursive tree models work. You have a general idea of how to access nodes on the tree, but you have no idea what’s there until you are close enough to touch it. File system access performance is limited by both the hardware on which the file system resides and the logic on the particular file system type. Those constraints erode away some of the performance benefits of using a lower level language. What ever operations you wish to perform must be individually applied on each node because you have no idea what’s there until you are touching it.
Second, because the operations are individually applied on each node it’s important to limit what those operations actually are. My application is only searching against a string fragment, absence of the string fragment, or a regular expression match. Wildcards are not supported and other extended search syntax is not supported. If you have to parse a rule each time before applying it to a string identifier of a node those are additional operations performed at each and every node in the designated segment of the tree.
For those familiar with the DOM in the browser it also has the same problems because it’s also a tree model. This is why querySelectors are so incredibly slow compared to walking the DOM with the boring old static DOM methods.
Earlier quoted context omitted.
Seconding. It takes doing some low-level gamedev[0] stuff, or using software written by people like Casey, to realize just how fast software can be. There's an art to it, and it hits diminishing returns with complex software, but the baseline of popular software is so low it doesn't take much more than a pinch of care to beat it by an order of magnitude. (Cue in the "but why bother, my app is IO bound anyway" counter…
I find it striking that a decent modern laptop would have been a supercomputer 20 years ago, when people used Office 97 that was feature complete already IMO. I can't help this constant cognitive dissonance with modern software; do we really need supercomputers to move Windows out of the box?
Earlier quoted context omitted.
I just launched "dir" https://i.imgur.com/lkbOR3i.png can't even print properly the decimal separator. maybe it wasn't that easy.
The font, m8, the font. Use monospcae font and it works like a charm.
Earlier quoted context omitted.
When I saw this mentioned on HN I immediately knew this kind of comment would be there because something along the lines and I am paraphrasing "its probably fast because its not enterprise enough" was repeated in every place the refterm was shared by different people even multiple times even after showing all the proof in the world that its in fact the opposite they almost refused to believe that software can be that…
Seconding. It takes doing some low-level gamedev[0] stuff, or using software written by people like Casey, to realize just how fast software can be. There's an art to it, and it hits diminishing returns with complex software, but the baseline of popular software is so low it doesn't take much more than a pinch of care to beat it by an order of magnitude. (Cue in the "but why bother, my app is IO bound anyway" counter…
while that's true, in this particular case with Casey's impl, it's not an art. The one thing that drastically improved performance, was caching. Literally the simplest, most obvious thing to do when you have performance problems.
This reflects a lot of what goes on in Academia as well. Also, if you think you can counter a "that's not possible" with a working proof of said thing working, think again, most people don't like to be shown they're wrong, particularly tenured professors. That's one of the fastest ways to sabotage your own developing career. "Yes men" climb the ladder much easier, but then work doesn't do itself so that's the catch.…
It really depends on the person, but yes you have to get to know them to know how they will react. I find that this is more of a problem in the US, where tenured professors often develop these vast impenetrable egos, while in other countries, such as in the UK or Germany, they are more pragmatic. That said it is still entirely individual, and I knew who to avoid when I had certain ideas in my PhD. Also, our German gr…
Earlier quoted context omitted.
This particular case was discussed at length on Reddit and on YC News. The general consensus was that the Microsoft developers simply didn't have performance in the vocabulary, and couldn't fathom it being a solvable problem despite having a trivial scenario on their hands with no complexity to it at all. The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] an…
> The "complaining developer" produced a proof of concept in just two weekends... That developer also was rather brusque in the github issue and could use a bit more humility and emotional intelligence. Which, by the way, isn't on the OP blog post's chart of a "programmers lifecycle". The same could be said of the MS side. Instead of both sides asserting (or "proving") that they're "right" could they not have collabo…
My experience with people that want to collaborate instead of just recognizing and following good advice is that you spend a tremendous amount of effort just to convince them to get their ass moving, then find out they were not capable of solving the problem in the first place, and it’s frankly just not worth it.
Much more fun to just reimplement the thing and then say “You were saying?”
I tihnk I generally agree with this, but also wonder what the alternative is. If you step outside your own industry, do you want plumbers that have a hobbiest appreciation of the intricacies of fluid dynamics, or do you want someone to come and unblock your toilet in the middle of the night? There's possibly a middle ground where the geniuses invent toilet technology in such a way that it is easy to install and maint…
Realistically though, a PhD is the opposite of what you want here. A PhD is almost by definition an inexperienced programmer. It's also someone who is likely to fall in love with their ideas, putting aesthetics or purity above practicality and effectiveness.
Earlier quoted context omitted.
The font, m8, the font. Use monospcae font and it works like a charm.
Does the GP's chosen font work correctly in Windows Terminal, though? If so, then that proves that there is indeed more to a fully functional terminal renderer than refterm covers.
That seems like it would be unaffected by correcting font rendering.