<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Firefox disk IO can be expensive on Windows. in Discussions</title>
    <link>https://connect.mozilla.org/t5/discussions/firefox-disk-io-can-be-expensive-on-windows/m-p/116951#M45644</link>
    <description>&lt;P&gt;Hello, I'd like to raise awareness that probably isn't apparently obvious to most developers working on Firefox.&lt;/P&gt;&lt;P&gt;This comes from an Anti-Malware perspective, where we try and optimize for known processes - something that's very hard to do on a web browser because it can access all sorts of nasty things.&lt;/P&gt;&lt;P&gt;Each time Firefox writes to disk in order to cache data, it calls `CreateFile` with read &amp;amp; write flags set. It'll do this many, many, times. When this happens, it generates events which Anti-Malware vendors will see and then take action on. Typically, this means scanning and churn within the AV product, which in turn will often slow the browser down because file access will be blocked until the AV product is done with it. On high-end machines the impact is often not noticeable, but on lower spec machines the impact is far easier to detect. Especially when there are many tabs open with many websites displaying dynamic data feeds.&lt;/P&gt;&lt;P&gt;I would therefore like to suggest that disk IO be changed to benefit overall experience for Windows users (and the few non-Windows users where those users have AV). Below are some suggestions off the top of my head.&lt;/P&gt;&lt;P&gt;1) Only set the write flag on FileOpen/CreateFile if a write is to be performed. If just reading from cache, open for read only.&lt;BR /&gt;2) Hold the file open until the browser is done with it. A procmon trace shows me tens of open close events on a single cache file in under 1 second, each with the write flag set, although I'm not convinced there's actually been a write.&lt;BR /&gt;3) Batch write operations - I appreciate this may not be possible as dynamic pages may update different parts of the page at different times all within the space of a second and that there is no way to know if there are more updates to follow.&lt;/P&gt;&lt;P&gt;Overall, though, please realise that each file write will likely trigger a scan and often so will a file read. Reading the file will often be delayed by the AV product as it will first assess that the file is "clean" before allowing the accessing process (in this case Firefox) to read it.&lt;/P&gt;</description>
    <pubDate>Thu, 29 Jan 2026 11:47:08 GMT</pubDate>
    <dc:creator>Anonymous_Jim</dc:creator>
    <dc:date>2026-01-29T11:47:08Z</dc:date>
    <item>
      <title>Firefox disk IO can be expensive on Windows.</title>
      <link>https://connect.mozilla.org/t5/discussions/firefox-disk-io-can-be-expensive-on-windows/m-p/116951#M45644</link>
      <description>&lt;P&gt;Hello, I'd like to raise awareness that probably isn't apparently obvious to most developers working on Firefox.&lt;/P&gt;&lt;P&gt;This comes from an Anti-Malware perspective, where we try and optimize for known processes - something that's very hard to do on a web browser because it can access all sorts of nasty things.&lt;/P&gt;&lt;P&gt;Each time Firefox writes to disk in order to cache data, it calls `CreateFile` with read &amp;amp; write flags set. It'll do this many, many, times. When this happens, it generates events which Anti-Malware vendors will see and then take action on. Typically, this means scanning and churn within the AV product, which in turn will often slow the browser down because file access will be blocked until the AV product is done with it. On high-end machines the impact is often not noticeable, but on lower spec machines the impact is far easier to detect. Especially when there are many tabs open with many websites displaying dynamic data feeds.&lt;/P&gt;&lt;P&gt;I would therefore like to suggest that disk IO be changed to benefit overall experience for Windows users (and the few non-Windows users where those users have AV). Below are some suggestions off the top of my head.&lt;/P&gt;&lt;P&gt;1) Only set the write flag on FileOpen/CreateFile if a write is to be performed. If just reading from cache, open for read only.&lt;BR /&gt;2) Hold the file open until the browser is done with it. A procmon trace shows me tens of open close events on a single cache file in under 1 second, each with the write flag set, although I'm not convinced there's actually been a write.&lt;BR /&gt;3) Batch write operations - I appreciate this may not be possible as dynamic pages may update different parts of the page at different times all within the space of a second and that there is no way to know if there are more updates to follow.&lt;/P&gt;&lt;P&gt;Overall, though, please realise that each file write will likely trigger a scan and often so will a file read. Reading the file will often be delayed by the AV product as it will first assess that the file is "clean" before allowing the accessing process (in this case Firefox) to read it.&lt;/P&gt;</description>
      <pubDate>Thu, 29 Jan 2026 11:47:08 GMT</pubDate>
      <guid>https://connect.mozilla.org/t5/discussions/firefox-disk-io-can-be-expensive-on-windows/m-p/116951#M45644</guid>
      <dc:creator>Anonymous_Jim</dc:creator>
      <dc:date>2026-01-29T11:47:08Z</dc:date>
    </item>
  </channel>
</rss>

