Wow! "NEW" Microsoft Teams!
-
@pcooper that’s the keyboard warmer feature to keep your hands warm while using Teams. Unrelated, there may be a high CPU usage bug in Teams.
-
@pcooper said in Wow! "NEW" Microsoft Teams!:
I'm very confused as to how New Microsoft Teams requires some sort of driver update for a new "thermal function". But it does seem likely that Microsoft or Lenovo is doing something very wrong here. (That's, of course, an inclusive "or".)
Teams is so poorly coded that it requires special thermal support to avoid the computer going
? 
(damn,
)
-
@pcooper Spacebar heating?
-
@Zerosquare that’s a standard feature of electron, no need for the
.My laptop once hard reset after using Teams for too long. (Although I think it’s since gotten better with hardware-accelerated video support or something)
-
@topspin said in Wow! "NEW" Microsoft Teams!:
My laptop once hard reset after using Teams for too long.
That's nothing! My brain hard reset after using Teams for too long.
-
@pcooper said in Wow! "NEW" Microsoft Teams!:
A new driver came out for my work laptop for the "Lenovo Intelligent Thermal Solution Driver". I like looking at the release notes before installing a driver update, just so I have a rough idea of what I might be in for when I install it.
Under "Changes in This Release":
[New functions or enhancements] - Added thermal function for New Microsoft Teams.I'm very confused as to how New Microsoft Teams requires some sort of driver update for a new "thermal function". But it does seem likely that Microsoft or Lenovo is doing something very wrong here. (That's, of course, an inclusive "or".)
It's probably for this feature
Damn.
-
@topspin said in Wow! "NEW" Microsoft Teams!:
@Zerosquare that’s a standard feature of electron, no need for the
.Somehow VSCode manages to be fairly performant (I'd say it beats VSClassic, which is in .нет) despite also being written in electron, which makes me think it's rather the web framework of the hour that's making most electron apps such crap.
-
@Bulb I came across a blog post today about this and how they did certain optimisations understanding how the JS engine works.
For example the core underlying model they use for handling text actually in buffers is a carefully modified piece table, or perhaps more accurately (as they call it a piece tree)
Text Buffer Reimplementation, a Visual Studio Code Story
Text Buffer Reimplementation in the Visual Studio Code/Monaco editor
They noted part of the old problem was shuffling between C++ and V8, so they resolved to cut out the pain by not shuffling between the two and ramping up the efficiency on the V8 side itself.
I'd say it seems to have worked. Will also agree that React (in particular) is a fucking monstrosity of performance suck.
-
@Bulb maybe, I'll have to take your word on that. I'm just reminded of the time they had to fix that "blinking text cursor causes 100% CPU usage" bug.
-
@Arantor said in Wow! "NEW" Microsoft Teams!:
For example the core underlying model they use for handling text actually in buffers is a carefully modified piece table, or perhaps more accurately (as they call it a piece tree)
Well, at least that might give you some ideas about about side-project-#5274 you asked about recently in the Lounge.
-
@Arantor said in Wow! "NEW" Microsoft Teams!:
They noted part of the old problem was shuffling between C++ and V8, so they resolved to cut out the pain by not shuffling between the two and ramping up the efficiency on the V8 side itself.
Any cloning of strings is bound to be a problem. C++-side allocation is slow and while V8-side allocation is fast, you pay for that with the extra garbage collection passes.
JITed code is almost as fast as natively compiled one for pure crunching power, it is the data structure and memory management overhead that makes the most difference. So if you can't bind the C++ data structure and have to convert it on access, that's bound to be worse.
I'd say it seems to have worked.
They optimized the heck of the data structure, and it worked. The same optimizations would be appropriate in any language. With some variation depending on the memory manager performance profile, but not all that much I'd say.
Will also agree that React (in particular) is a fucking monstrosity of performance suck.
Yeah, react is fairly easy to start with, simple and flexible, but well into the worse half of the benchmark. And easy to lose track of the bigger picture if you don't have a good architect—since in React the components tend to keep their own state (model), it's easy to end up with bunch of duplicate calls to the back-end, destroying all hope for any semblance of performance.
-
@topspin said in Wow! "NEW" Microsoft Teams!:
@Arantor said in Wow! "NEW" Microsoft Teams!:
For example the core underlying model they use for handling text actually in buffers is a carefully modified piece table, or perhaps more accurately (as they call it a piece tree)
Well, at least that might give you some ideas about about side-project-#5274 you asked about recently in the Lounge.
How do you think I found that article in the first place????
-
@Bulb said in Wow! "NEW" Microsoft Teams!:
@topspin said in Wow! "NEW" Microsoft Teams!:
@Zerosquare that’s a standard feature of electron, no need for the
.Somehow VSCode manages to be fairly performant (I'd say it beats VSClassic, which is in .нет) despite also being written in electron, which makes me think it's rather the web framework of the hour that's making most electron apps such crap.
Lately it's been locking up on me a few times per day. I suspect that's extension related, though, TBH. Overall I really like it.
-
@boomzilla Yeah, actually I spent most of yesterday chasing a problem of crashing devcontainer, which turned out to be because vscode writes a
~/.docker/config.jsonwithcredsStoresetting that tries to forward the request to thecredsStoreoutside the container, but a) there ain't none outside, and b) the forwarding crashes when called withlistargument—which docker apparently doesn't do, but the library I was using does.But otherwise devcontainers are a pretty good feature that they came up with.
-
@Bulb said in Wow! "NEW" Microsoft Teams!:
C++-side allocation is slow
It doesn't have to be, but the default allocator has to be rather pessimistic.
-
@dkf A bump-allocator used with copying garbage collectors will always be faster for allocation, but then you pay with copying the objects that survived generation zero and updating all the references in the process.
-
@Bulb I was thinking more about the fact that the default allocator needs to be multithreaded-safe, including allowing one thread to deallocate what was allocated on another. Most allocations stay in their thread (at least for the two ends of their lifetime); you pay the tax of a global lock for a feature you hardly use...
-
@dkf You don't need a global lock, at least not most of the time. The better optimized allocators use per-thread magazines. But many standard libraries are not as optimized.
Also a generational copying GC can have a per-thread gen0, but while marking can be done in parallel to mutation, copying can't, so it has to occasionally stop the world for that. Which C++ doesn't.
-
@Bulb The really big gains come if you can fit in an assumption that you have a lot of memory objects of the same size. (Some apps fit that model, but not all.) If you do, you can "allocate" the objects in an array, which lets you avoid a very large amount of per-object space overhead, and space and time are rather linked. (There are other aspects to this sort of trickery, but you should be expecting to be getting the array storage directly from the system page allocator.)
It's not a universal solution, but my real point was that the universal solutions have overhead that specific solutions do not.
-
@dkf Therer are universal solutions that do all those optimizations. It's not that hard actually. Strangely enough FreeBSD does use one such, but Linux or Windows didn't adopt anything even close to similar (to GNU Libc credit it at least makes it possible to reliably plug in a different allocator).
-
@Bulb last time I tried to google that, the benchmarks for the plethora of different allocators tested had no clear winners in terms of different usage patterns. Although pretty much all of them beat their reference.
I've heard good things about mimalloc (which of course is best in their own benchmark suite, but that was true of a few others), which is almost surprising given how shit the default allocator on Windows performs. Maybe I should test it at some point.
In the meantime, I've implemented a simple / stupid block allocator for fixed sizes, with thread affinity / no locking and a trivial free list.
-
@topspin said in Wow! "NEW" Microsoft Teams!:
In the meantime, I've implemented a simple / stupid block allocator for fixed sizes, with thread affinity / no locking and a trivial free list.
That works great unless you want to return pages to the OS. Safely deallocating the pages is where things get rather hairier. (On the other hand, users get grumbly if the headline memory consumption gets too large...)
-
@dkf said in Wow! "NEW" Microsoft Teams!:
That works great unless you want to return pages to the OS.
Memory is returned to the OS on process termination.
I did say a simple-stupid allocator.
-
@topspin I know that's where we ended up going on the previous project. Big daemon, all dynamic memory came from block pools. Memory was released back to the pools but never to the OS.
-
-
@boomzilla I mean FFS. If I got that, I'd be questioning whether my install is legit or I had somehow attained it from some counterfeit site. That's one of the biggest benefits of Microsoft Defender (or any good AV).
My employer, small company, got acquired by a bigger company years ago. To this day there are parts of us that throw false positives to their IT team because there's still certain activity with our old domain. Despite that domain having been thoroughly scrutinized to ensure they abide by the global policies and best practices they refuse to just adopt our domain as part of their umbrella.
-
@The_Quiet_One said in Wow! "NEW" Microsoft Teams!:
Unsure if any 'good' ones exist anymore.
"Good" ones exist. Good ones without the scare quotes are another matter.
x.com
