7 ms·

> I don't think it's the FireFox' team's responsibility to be aware of and take into account arbitrary software intercepting system calls. Per the bug report,

by vntok 4y ago

> I don't think it's the FireFox' team's responsibility to be aware of and take into account arbitrary software intercepting system calls. Per the bug report, Firefox was generating up to ~14,000 calls where Chrome was generating ~300, though. Surely it is Firefox' team's responsibility to use system calls in a sane way, say not almost 50x more than the competition?

jupp0r 4y ago
Did you read the bug report? This is literally about writing to files in a temp folder. Surely you can optimize that but you should also be able to assume that this does not use excessive amounts of CPU on a modern operating system.
- vntok 4y ago
  Yes, I have read the bug report. It mentions that Firefox writes wayyyyy too much in the temp folder. It also mentions that the team should fix this behaviour independently of the fact that some of those calls are more costly than they should be because of the bug in Defender: > With a standard Firefox configuration, the amount of calls to VirtualProtect is currently very high, and that is what explains the high CPU usage with Firefox. The information that the most impactful event originates from calls to VirtualProtect was forwarded to us by Microsoft, and I confirm it. In Firefox, disabling JIT makes MsMpEng.exe behave much more reasonably, as JIT engines are the source of the vast majority of calls to VirtualProtect. > On Firefox's side, independently from the issue mentioned above, we should not consider that calls to VirtualProtect are cheap. We should look for opportunities to group multiple calls to VirtualProtect together, if possible. Even after the performance issue will be mitigated, each call to VirtualProtect will still trigger some amount of computation in MsMpEng.exe (or third-party AV software); the computation will just be more reasonably expensive.
  - cesarb 4y ago
    > It mentions that Firefox writes wayyyyy too much in the temp folder. > > the amount of calls to VirtualProtect is currently very high Calling VirtualProtect is not writing to the temp folder. The VirtualProtect call is to change the permissions of the in-memory pages. It should be an inexpensive system call (other than the cost of TLB flushes and/or shootdowns).
- deleted 4y ago
  [deleted]
- BuckRogers 4y ago
  You really shouldn’t assume anything in software or any complex system. I know this wouldn’t fly at my job, and I don’t work at Mozilla. This is basic testing. Normally this is the mark of a bad software engineer, but attempting to blame the platform you’re on for your lack of testing takes it a to a new low. Mistakes happen, admitting full incompetence that basic testing isn’t done is damning. This is not a good defense of Firefox nor Mozilla.
  - jupp0r 4y ago
    Not sure what your job is, but in my job: - we implement a feature, test it thoroughly for functional and non-functional requirements - when we are happy, we release it I don't see myself being responsible for a third party software company coming along years later and introducing a bug in code that injects itself between my software and the operating system that users of the software I wrote happens to install at some point.
    - dpkirchner 4y ago
      Maybe you're not responsible, but if someone says "something changed in the OS and your previous method is now adding substantial overhead", you could either a) report the change to the OS and mitigate or b) report the change to the OS and ignore the problem for years. It sounds like Mozilla chose b, for whatever reason. As a software developer, I've had to workaround many many bugs in OSs, especially when dealing with updates to Android. It's just part of the job.
    - thfuran 4y ago
      The OS isn't some random third party software, it's one of your dependencies. Your software doesn't work without the OS and if it also doesn't work with the OS, it just plain doesn't work.
      - wtallis 4y ago
        That's really not a tenable mindset to be taking these days. With how much Windows has become a constantly-moving target rather than a stable platform, you need to regard it first and foremost as your adversary, whether you are developing against it or are simply an end user. And the days of being able to thoroughly test against every relevant version of the OS are long gone; Microsoft has ensured your QA will be Sisyphean.
- thfuran 4y ago
  I usually assume that even vaguely considering looking in the same direction as a file on windows will melt my CPU.
  - hgsgm 4y ago
    Windows Search Indexer automates that for me. CPU keeps burning even when monitor is off and I'm working on another computer.
    - 0cf8612b2e1e 4y ago
      Why is Search Indexer constantly rescanning the same files? Can they not cache the results from the previous scan? That and OneDrive are constantly making my work laptop scream.
- IshKebab 4y ago
  Come on, anyone that has even unzipped Linux-centric stuff on Windows knows how slow individual file operations are compared to Mac or Linux. It's very common knowledge that on Windows you will get terrible performance if you have many many small files. I don't know why Microsoft doesn't fix that. Maybe they can't for compatibility reasons or something. But that's the way it is, and any software that wants to run well on Windows needs to deal with it by using fewer bigger files.
bogwog 4y ago
> Surely it is Firefox' team's responsibility to use system calls in a sane way, say not almost 50x more than the competition? The docs for that function don't say anything about performance: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect https://learn.microsoft.com/en-us/windows/win32/api/memoryap... They also don't say anything about "sane" usage, and while I don't have an MBA, I'm pretty sure they don't teach anything about `VirtualProtect` ratios when doing competitor analysis. One possibility is that the Chrome team's implementation was more efficient due to luck, or they invested the resources to identify the performance characteristics of this function call, whereas the Firefox team missed it. I don't think "Chrome has more development resources than Firefox" is news to anybody.
- deleted 4y ago
  [deleted]
- shadowgovt 4y ago
  There are three facets to any protocol, API, or standard in software: The spec, the intent of the spec, and the implementation of the spec. Doesn't matter what the docs say; what matters is what performance testing shows. Docs lie. And even if Chrome lucked into a cheaper implementation: that luck has given them a market edge.

by vntok 4y ago

jupp0r 4y ago

Did you read the bug report? This is literally about writing to files in a temp folder. Surely you can optimize that but you should also be able to assume that this does not use excessive amounts of CPU on a modern operating system.

vntok 4y ago
Yes, I have read the bug report. It mentions that Firefox writes wayyyyy too much in the temp folder. It also mentions that the team should fix this behaviour independently of the fact that some of those calls are more costly than they should be because of the bug in Defender: > With a standard Firefox configuration, the amount of calls to VirtualProtect is currently very high, and that is what explains the high CPU usage with Firefox. The information that the most impactful event originates from calls to VirtualProtect was forwarded to us by Microsoft, and I confirm it. In Firefox, disabling JIT makes MsMpEng.exe behave much more reasonably, as JIT engines are the source of the vast majority of calls to VirtualProtect. > On Firefox's side, independently from the issue mentioned above, we should not consider that calls to VirtualProtect are cheap. We should look for opportunities to group multiple calls to VirtualProtect together, if possible. Even after the performance issue will be mitigated, each call to VirtualProtect will still trigger some amount of computation in MsMpEng.exe (or third-party AV software); the computation will just be more reasonably expensive.
- cesarb 4y ago
  > It mentions that Firefox writes wayyyyy too much in the temp folder. > > the amount of calls to VirtualProtect is currently very high Calling VirtualProtect is not writing to the temp folder. The VirtualProtect call is to change the permissions of the in-memory pages. It should be an inexpensive system call (other than the cost of TLB flushes and/or shootdowns).
deleted 4y ago
[deleted]
BuckRogers 4y ago
You really shouldn’t assume anything in software or any complex system. I know this wouldn’t fly at my job, and I don’t work at Mozilla. This is basic testing. Normally this is the mark of a bad software engineer, but attempting to blame the platform you’re on for your lack of testing takes it a to a new low. Mistakes happen, admitting full incompetence that basic testing isn’t done is damning. This is not a good defense of Firefox nor Mozilla.
- jupp0r 4y ago
  Not sure what your job is, but in my job: - we implement a feature, test it thoroughly for functional and non-functional requirements - when we are happy, we release it I don't see myself being responsible for a third party software company coming along years later and introducing a bug in code that injects itself between my software and the operating system that users of the software I wrote happens to install at some point.
  - dpkirchner 4y ago
    Maybe you're not responsible, but if someone says "something changed in the OS and your previous method is now adding substantial overhead", you could either a) report the change to the OS and mitigate or b) report the change to the OS and ignore the problem for years. It sounds like Mozilla chose b, for whatever reason. As a software developer, I've had to workaround many many bugs in OSs, especially when dealing with updates to Android. It's just part of the job.
  - thfuran 4y ago
    The OS isn't some random third party software, it's one of your dependencies. Your software doesn't work without the OS and if it also doesn't work with the OS, it just plain doesn't work.
    - wtallis 4y ago
      That's really not a tenable mindset to be taking these days. With how much Windows has become a constantly-moving target rather than a stable platform, you need to regard it first and foremost as your adversary, whether you are developing against it or are simply an end user. And the days of being able to thoroughly test against every relevant version of the OS are long gone; Microsoft has ensured your QA will be Sisyphean.
thfuran 4y ago
I usually assume that even vaguely considering looking in the same direction as a file on windows will melt my CPU.
- hgsgm 4y ago
  Windows Search Indexer automates that for me. CPU keeps burning even when monitor is off and I'm working on another computer.
  - 0cf8612b2e1e 4y ago
    Why is Search Indexer constantly rescanning the same files? Can they not cache the results from the previous scan? That and OneDrive are constantly making my work laptop scream.
IshKebab 4y ago
Come on, anyone that has even unzipped Linux-centric stuff on Windows knows how slow individual file operations are compared to Mac or Linux. It's very common knowledge that on Windows you will get terrible performance if you have many many small files. I don't know why Microsoft doesn't fix that. Maybe they can't for compatibility reasons or something. But that's the way it is, and any software that wants to run well on Windows needs to deal with it by using fewer bigger files.

bogwog 4y ago

> Surely it is Firefox' team's responsibility to use system calls in a sane way, say not almost 50x more than the competition? The docs for that function don't say anything about performance: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect https://learn.microsoft.com/en-us/windows/win32/api/memoryap... They also don't say anything about "sane" usage, and while I don't have an MBA, I'm pretty sure they don't teach anything about `VirtualProtect` ratios when doing competitor analysis. One possibility is that the Chrome team's implementation was more efficient due to luck, or they invested the resources to identify the performance characteristics of this function call, whereas the Firefox team missed it. I don't think "Chrome has more development resources than Firefox" is news to anybody.

deleted 4y ago
[deleted]
shadowgovt 4y ago
There are three facets to any protocol, API, or standard in software: The spec, the intent of the spec, and the implementation of the spec. Doesn't matter what the docs say; what matters is what performance testing shows. Docs lie. And even if Chrome lucked into a cheaper implementation: that luck has given them a market edge.