The most incredible thing about the new iPads is that even with the crazy fast M4 chip MS Teams manages to crawl to a halt. Clearly it takes all the engineering skills of the largest and most valuable software company in the world to make text entry go at about 1 fps on a chip as powerful as the M4.
Every character you type results in some sort of hit to their telemetry server. It will include the actual letter you typed, if you or your org are not configured to be in EU. With their EU configuration option (pulled from server every launch) it will only report the fact that you typed _something_.
Now if that's not fun enough, their telemetry also covers mouse movements. Go ahead and watch your CPU as you spin your mouse in circles around the Teams window.
For extra fun, block their telemetry server and watch Teams bloat in RAM, to as much as your system has, as it keeps every action you take in local memory as it waits for the ability to talk to that telemetry server again.
If you're going to block their telemetry its best to fake an accept via some mitm proxy and send back a 200 code.
I do not know exactly how much this applies to iPad version, compared to their desktop apps. Mobile offers both more and less data possibilities. It's a different context.
So they’re running a keystroke logger and masquerading it as “telemetry”? That should be outlawed. It’s not a drafts feature, it’s not an online word processor, it’s just a straight up keystroke logger.
I’m in the EU and should have the EU configuration.
The problem mainly occurs when I mention someone in a reply to a thread. Once I type @<name> the text input just slows down so much I can type much faster than it can render the text.
It's still going through the same telemetry action, it just omits the actual character you typed. And yes, it is character by character. That collection (eg, the timestamp you hit the character, channel/person it was to, etc) is the inefficiency causing your typing to slow.
If it was a straight text box that they polled contents of _occasionally_ or after you hit 'send', it would be a much better user experience.
Haha what exactly does it protect me from? If they see that I typed something to someone, and see the chat history of me having sent a particular message at a particular time, it doesn't take a genius to put things together.
As much as I dislike overbearing telemetry in the context of an M4 or even an N95 the computer should be more than capable of logging a few kb of telemetry about inputs per second without even a notice on the performance statistics. The problem remains that every single thing in the app is just implemented god awful slow and would still be regardless if it's also recording telemetry on the input data or not.
...do you have any source verifying this? Setting aside how insane of an issue it'd be network-wise/privacy-wise/etc, this is like a day one "debounce the call" fix.
I'm not even saying I doubt you, I'm just curious how you ascertained this exact behavior.
Mainly this was just myself getting irritated at MS Teams and trying to figure out what it was doing. It was a couple years ago and my current company doesn't use teams, thankfully, so I can't really see if its still valid.
From what I remember..
There are files on the disk that get updated/overwritten with pulls from the server every time it launches. Somewhere in AppData I think. A few of these are config files (with lots of interesting looking settings, including beta features).
One of the config entries specifies a telemetry endpoint (which, you _could_ figure out with a network tracing tool but there are a ton of MS telemetry endpoints your machine is probably talking to. Best to just grab the one explicitly being used from the config like this). I forget the full name of the setting but the name pretty clearly indicates its for telemetry, and the file is clearly a config file. If you can't find it just by browsing the structure, try a multi-file search tool and look for 'telemetry' or URL/hostnames.
You can't really change the value on disk and make it just take effect from there, since it gets downloaded from the server and overwritten before Teams loads. There might be some tricks you can do locally to persist the change but nothing seemed to work for me. You could override response from server via mitmproxy but that requires finding where it comes across the wire at launch time and then building a script/config to replace it.
Anyway, you can block that telemetry endpoint from a firewall and see your memory bloat. Or you can intercept that endpoint in any mitm proxy. I went with this [mitmproxy](https://mitmproxy.org/). From there you can capture the content it sends to the endpoint, or even change the response the server sends (Teams just seems to expect a 200 code back).
The telemetry data itself is some kind of streaming event format. I think I even found documentation on the structure on some microsoft website, so its likely a reused format.
It's pretty straightforward.
I couldn't spend too much time on it and now it's not something I even use, but some cool things you might want to try if you dive deeper into this:
- Overwrite the config file as it returns from the server, to turn on EU data protection, change various functionality you're not supposed to, or flip some feature flags.
- Figure out if there's a feature flag or even other overwrite to fully disable the metrics so they aren't even collected, from anywhere in the app.
- Intercept telemetry, return an 'OK' response and drop the data from telemetry, or maybe document what they collect more definitively if you think there's interest somewhere. This keeps your privacy but doesn't really do anything for performance.
- Interfere with the data before actually returning it, maybe try playing with event contents and channel/user indicators. Microsoft probably won't like this if they notice, but it's unlikely they'll even notice.
No clue why they're even doing this and not just sampling after the fact. There's no way they are gleaning anything useful that they couldn't more efficiency (and anonymously) capture.
Ah, that's right, Chrom* based things look at the system store by default and it's the Firefox based things that don't (without configuration at least). Thanks.
Edit: and that reminds me I should probably run this test on new Teams, where it now uses the built in WebView2
Is the telemetry really that big of a load? Having a persistent connection and sending data over it is pretty standard for games going back decades, even AOL instant messenger had this feature for typing.
Asana used to sometimes have textareas that would take a full three seconds to display each key press. On then-current MacBook pros. You know, something that had nearly zero latency on first-gen single-core Pentium chips. Hell it may still do that, I never saw them fix it, I just finally got to stop using it.
Never underestimate the ability of shitware vendors to make supercomputers feel slower than an 8086. These days it usually involves JavaScript, HTML, and CSS.
MS Teams is by far the worst piece of software I’ve ever used. It is ungodly slow and it just gets slower the more you use it.
I believe it is actually hitting the server to update the online/away status light for every single message in a conversation. If you turn off all the status update stuff in the settings then the software speeds up dramatically. Another thing you can do is find the folder where it caches everything and just trash the entire thing. Somehow, they’ve managed to make caching slow everything down rather than provide a speed up.
I use it exclusively as a progressive web app on Linux and it's not particularly slow, but it is buggy as all hell. Easily the worst rich text editing experience of any chat client I've ever used. Teams is without a doubt the worst piece of software I'm required to use on a daily basis
Why is that not at least done asynchronously? I thought part of the whole narrative of shipping these new terrible pieces of software as standalone Google Chrome instances was that it makes it easier to spawn async JS workers for background tasks and whatnot?
async is still difficult. There is no getting around data synchronization issues. either you need to spend a lot of time in design or will get constant problems with things like not having a mutex when you should, mutex deadlock, holding a mutex too long, locking/unlocking too often.
I haven't done async JS, but I've done enough async elsewhere to know that language cannot work around bad design.
You still need to design a CRDT that solves your particular problem, you don't just say the magic word "CRDT" and the problem is gone. And the performance will depend on how good the design is.
I think that’s what it’s doing. If you have a conversation with a person spanning hundreds of messages (over many weeks) it’ll be updating the status light next to their name on every single message in the history. The more messages in the history, the more workers you get!
LOL, you wanna try it on my ~2 generations old Core i5 corporate laptop. Sometimes, the first steps of drawing the calendar view are roughly the same speed as me drawing it in Paint.
Maybe someone should normalise giving developers crappy laptops to develop on.
(Has anyone done a deep dive into Teams to explain what on earth is going on? I mean, if VSCode can be fast despite its underlying architecture, surely something could be done about Teams?)
>> Maybe someone should normalise giving developers crappy laptops to develop on.
Then the developers will complain the hardware is unusable to do their job even though that this was a supercomputer back in the day. Then you say "No, it's the software please fix it."
Yup, my work machine has an older i7 (2021-era maybe?) with 32GB RAM and between Teams, Slack, "new" Outlook, Jira, WSL, driving a 4K display off the piddly integrated GPU, and a VPN that involves every packet doing a transatlantic roundtrip whenever I want to connect to an internal service, everything is just dog slow. And the fan noise—my god the fan noise.
Some days it makes me extra motivated to make the code I write fast and efficient; other days I want to give up entirely.
Do companies using Teams have a choice of using something else or are their C*Os and IT departments married with Microsoft? If the latter, they'll use whatever Microsoft throws at them, even if it doesn't work.
Weird, a statically built ELF that supports TLS1.3 + HTTP1.1 is like ~30kb, all you need is Emacs as a UI and you have Teams 2 at 1.0e-5% resource usage.
Try Pidgin with the excellent ms teams plugin: https://github.com/EionRobb/purple-teams - less than 100mb ram usage and notifications that still work after an hour. Only for (video) calls you need to open teams..
Teams on the desktop has improved with their "v2" client. It's not the world's fastest piece of software, but I find it to not be embarrassingly slow now (on a reasonably specced machine).
One as to hope that the same perfomance lens will now be turned on the mobile apps.
