Tracking issue for some thread pool experiments (.NET 8) #77665

Description

@kouvel

This issue tracks some thread pool experiments/investigations that were proposed.

  • Polling for IO on worker threads
    • There can be some tradeoffs between using dedicated IO poller threads and polling for IO on worker threads. Some issues observed in some cases with dedicated IO pollers is the thread scheduling latency, difficulty of determining a number of IO pollers on machines of various sizes, and the extra thread hop in processing IO events.
    • Build a prototype for experimenting with and collect some performance data to understand the pros and cons. In progress.
    • Use one global epoll fd and determine an alternate mechanism to assiciate an IO event with a callback
    • Experiment with some strategies for polling for IO to balance the overhead, such as frequency of polling, batch sizes, etc.
  • Using the Windows thread pool
    • There can be some tradeoffs in using the Windows thread pool, it may be beneficial in cases where other components also use the Windows thread pool. The goal is to experiment with using it and collect some data to understand some of the tradeoffs.
    • Experiment with using the Windows thread pool in coreclr and measure perf. In progress.
    • Investigate regressions and determine if they can be reasonably fixed
  • Processing IO events at higher priority on Unixes
    • IO events are processed in the same order as global work items, so in cases where the global queues are heavily backed up, in-progress requests could be delayed by processing of new requests. The goal is mainly to try it out and to understand any perf regressions.
    • Build System.Net.Sockets against CoreLib, queue processing of IO events at high priority, and gather some perf data
    • Investigate regressions and determine if they can be reasonably fixed. Most of the ASP.NET benchmarks resulted in regressions. After some investigation and experimentation the regressions appeared to reduce in magnitude on some tests, but still there. Needs further investigation to determine if this can reasonably be done on Unixes without perf regressions.
  • Disabling hill climbing
    • This is a quick experiment to just measure the current perf effects of disabling hill climbing. Hill climbing adds some costs and it was seen that it doesn't help in several kinds of apps.
    • Gather some current perf data to understand the effects of disabling hill climbing. Perf in ASP.NET benchmarks appears to be mostly similar or slightly better. Perf metrics in a large internal service did not change, but with fewer worker threads on average.

Some leftover work items are tracked in #52701.

Metadata

Metadata

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
     blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
    }
    } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
    })();
    (function(){
    try {
    var __m = "github.com";
    var __re = new RegExp('^' + "github\\.com" + '
    
    Skip to content

    Tracking issue for some thread pool experiments (.NET 8) #77665

    Description

    @kouvel

    This issue tracks some thread pool experiments/investigations that were proposed.

    • Polling for IO on worker threads
      • There can be some tradeoffs between using dedicated IO poller threads and polling for IO on worker threads. Some issues observed in some cases with dedicated IO pollers is the thread scheduling latency, difficulty of determining a number of IO pollers on machines of various sizes, and the extra thread hop in processing IO events.
      • Build a prototype for experimenting with and collect some performance data to understand the pros and cons. In progress.
      • Use one global epoll fd and determine an alternate mechanism to assiciate an IO event with a callback
      • Experiment with some strategies for polling for IO to balance the overhead, such as frequency of polling, batch sizes, etc.
    • Using the Windows thread pool
      • There can be some tradeoffs in using the Windows thread pool, it may be beneficial in cases where other components also use the Windows thread pool. The goal is to experiment with using it and collect some data to understand some of the tradeoffs.
      • Experiment with using the Windows thread pool in coreclr and measure perf. In progress.
      • Investigate regressions and determine if they can be reasonably fixed
    • Processing IO events at higher priority on Unixes
      • IO events are processed in the same order as global work items, so in cases where the global queues are heavily backed up, in-progress requests could be delayed by processing of new requests. The goal is mainly to try it out and to understand any perf regressions.
      • Build System.Net.Sockets against CoreLib, queue processing of IO events at high priority, and gather some perf data
      • Investigate regressions and determine if they can be reasonably fixed. Most of the ASP.NET benchmarks resulted in regressions. After some investigation and experimentation the regressions appeared to reduce in magnitude on some tests, but still there. Needs further investigation to determine if this can reasonably be done on Unixes without perf regressions.
    • Disabling hill climbing
      • This is a quick experiment to just measure the current perf effects of disabling hill climbing. Hill climbing adds some costs and it was seen that it doesn't help in several kinds of apps.
      • Gather some current perf data to understand the effects of disabling hill climbing. Perf in ASP.NET benchmarks appears to be mostly similar or slightly better. Perf metrics in a large internal service did not change, but with fewer worker threads on average.

    Some leftover work items are tracked in #52701.

    Metadata

    Metadata

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
      Skip to content

      Tracking issue for some thread pool experiments (.NET 8) #77665

      Description

      @kouvel

      This issue tracks some thread pool experiments/investigations that were proposed.

      • Polling for IO on worker threads
        • There can be some tradeoffs between using dedicated IO poller threads and polling for IO on worker threads. Some issues observed in some cases with dedicated IO pollers is the thread scheduling latency, difficulty of determining a number of IO pollers on machines of various sizes, and the extra thread hop in processing IO events.
        • Build a prototype for experimenting with and collect some performance data to understand the pros and cons. In progress.
        • Use one global epoll fd and determine an alternate mechanism to assiciate an IO event with a callback
        • Experiment with some strategies for polling for IO to balance the overhead, such as frequency of polling, batch sizes, etc.
      • Using the Windows thread pool
        • There can be some tradeoffs in using the Windows thread pool, it may be beneficial in cases where other components also use the Windows thread pool. The goal is to experiment with using it and collect some data to understand some of the tradeoffs.
        • Experiment with using the Windows thread pool in coreclr and measure perf. In progress.
        • Investigate regressions and determine if they can be reasonably fixed
      • Processing IO events at higher priority on Unixes
        • IO events are processed in the same order as global work items, so in cases where the global queues are heavily backed up, in-progress requests could be delayed by processing of new requests. The goal is mainly to try it out and to understand any perf regressions.
        • Build System.Net.Sockets against CoreLib, queue processing of IO events at high priority, and gather some perf data
        • Investigate regressions and determine if they can be reasonably fixed. Most of the ASP.NET benchmarks resulted in regressions. After some investigation and experimentation the regressions appeared to reduce in magnitude on some tests, but still there. Needs further investigation to determine if this can reasonably be done on Unixes without perf regressions.
      • Disabling hill climbing
        • This is a quick experiment to just measure the current perf effects of disabling hill climbing. Hill climbing adds some costs and it was seen that it doesn't help in several kinds of apps.
        • Gather some current perf data to understand the effects of disabling hill climbing. Perf in ASP.NET benchmarks appears to be mostly similar or slightly better. Perf metrics in a large internal service did not change, but with fewer worker threads on average.

      Some leftover work items are tracked in #52701.

      Metadata

      Metadata

      Type

      No type

      Projects

      No projects

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions

        , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
        Skip to content

        Tracking issue for some thread pool experiments (.NET 8) #77665

        Description

        @kouvel

        This issue tracks some thread pool experiments/investigations that were proposed.

        • Polling for IO on worker threads
          • There can be some tradeoffs between using dedicated IO poller threads and polling for IO on worker threads. Some issues observed in some cases with dedicated IO pollers is the thread scheduling latency, difficulty of determining a number of IO pollers on machines of various sizes, and the extra thread hop in processing IO events.
          • Build a prototype for experimenting with and collect some performance data to understand the pros and cons. In progress.
          • Use one global epoll fd and determine an alternate mechanism to assiciate an IO event with a callback
          • Experiment with some strategies for polling for IO to balance the overhead, such as frequency of polling, batch sizes, etc.
        • Using the Windows thread pool
          • There can be some tradeoffs in using the Windows thread pool, it may be beneficial in cases where other components also use the Windows thread pool. The goal is to experiment with using it and collect some data to understand some of the tradeoffs.
          • Experiment with using the Windows thread pool in coreclr and measure perf. In progress.
          • Investigate regressions and determine if they can be reasonably fixed
        • Processing IO events at higher priority on Unixes
          • IO events are processed in the same order as global work items, so in cases where the global queues are heavily backed up, in-progress requests could be delayed by processing of new requests. The goal is mainly to try it out and to understand any perf regressions.
          • Build System.Net.Sockets against CoreLib, queue processing of IO events at high priority, and gather some perf data
          • Investigate regressions and determine if they can be reasonably fixed. Most of the ASP.NET benchmarks resulted in regressions. After some investigation and experimentation the regressions appeared to reduce in magnitude on some tests, but still there. Needs further investigation to determine if this can reasonably be done on Unixes without perf regressions.
        • Disabling hill climbing
          • This is a quick experiment to just measure the current perf effects of disabling hill climbing. Hill climbing adds some costs and it was seen that it doesn't help in several kinds of apps.
          • Gather some current perf data to understand the effects of disabling hill climbing. Perf in ASP.NET benchmarks appears to be mostly similar or slightly better. Perf metrics in a large internal service did not change, but with fewer worker threads on average.

        Some leftover work items are tracked in #52701.

        Metadata

        Metadata

        Type

        No type

        Projects

        No projects

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
          Skip to content

          Tracking issue for some thread pool experiments (.NET 8) #77665

          Description

          @kouvel

          This issue tracks some thread pool experiments/investigations that were proposed.

          • Polling for IO on worker threads
            • There can be some tradeoffs between using dedicated IO poller threads and polling for IO on worker threads. Some issues observed in some cases with dedicated IO pollers is the thread scheduling latency, difficulty of determining a number of IO pollers on machines of various sizes, and the extra thread hop in processing IO events.
            • Build a prototype for experimenting with and collect some performance data to understand the pros and cons. In progress.
            • Use one global epoll fd and determine an alternate mechanism to assiciate an IO event with a callback
            • Experiment with some strategies for polling for IO to balance the overhead, such as frequency of polling, batch sizes, etc.
          • Using the Windows thread pool
            • There can be some tradeoffs in using the Windows thread pool, it may be beneficial in cases where other components also use the Windows thread pool. The goal is to experiment with using it and collect some data to understand some of the tradeoffs.
            • Experiment with using the Windows thread pool in coreclr and measure perf. In progress.
            • Investigate regressions and determine if they can be reasonably fixed
          • Processing IO events at higher priority on Unixes
            • IO events are processed in the same order as global work items, so in cases where the global queues are heavily backed up, in-progress requests could be delayed by processing of new requests. The goal is mainly to try it out and to understand any perf regressions.
            • Build System.Net.Sockets against CoreLib, queue processing of IO events at high priority, and gather some perf data
            • Investigate regressions and determine if they can be reasonably fixed. Most of the ASP.NET benchmarks resulted in regressions. After some investigation and experimentation the regressions appeared to reduce in magnitude on some tests, but still there. Needs further investigation to determine if this can reasonably be done on Unixes without perf regressions.
          • Disabling hill climbing
            • This is a quick experiment to just measure the current perf effects of disabling hill climbing. Hill climbing adds some costs and it was seen that it doesn't help in several kinds of apps.
            • Gather some current perf data to understand the effects of disabling hill climbing. Perf in ASP.NET benchmarks appears to be mostly similar or slightly better. Perf metrics in a large internal service did not change, but with fewer worker threads on average.

          Some leftover work items are tracked in #52701.

          Metadata

          Metadata

          Type

          No type

          Projects

          No projects

            Relationships

            None yet

            Development

            No branches or pull requests

            Issue actions

            , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
            Skip to content

            Tracking issue for some thread pool experiments (.NET 8) #77665

            Description

            @kouvel

            This issue tracks some thread pool experiments/investigations that were proposed.

            • Polling for IO on worker threads
              • There can be some tradeoffs between using dedicated IO poller threads and polling for IO on worker threads. Some issues observed in some cases with dedicated IO pollers is the thread scheduling latency, difficulty of determining a number of IO pollers on machines of various sizes, and the extra thread hop in processing IO events.
              • Build a prototype for experimenting with and collect some performance data to understand the pros and cons. In progress.
              • Use one global epoll fd and determine an alternate mechanism to assiciate an IO event with a callback
              • Experiment with some strategies for polling for IO to balance the overhead, such as frequency of polling, batch sizes, etc.
            • Using the Windows thread pool
              • There can be some tradeoffs in using the Windows thread pool, it may be beneficial in cases where other components also use the Windows thread pool. The goal is to experiment with using it and collect some data to understand some of the tradeoffs.
              • Experiment with using the Windows thread pool in coreclr and measure perf. In progress.
              • Investigate regressions and determine if they can be reasonably fixed
            • Processing IO events at higher priority on Unixes
              • IO events are processed in the same order as global work items, so in cases where the global queues are heavily backed up, in-progress requests could be delayed by processing of new requests. The goal is mainly to try it out and to understand any perf regressions.
              • Build System.Net.Sockets against CoreLib, queue processing of IO events at high priority, and gather some perf data
              • Investigate regressions and determine if they can be reasonably fixed. Most of the ASP.NET benchmarks resulted in regressions. After some investigation and experimentation the regressions appeared to reduce in magnitude on some tests, but still there. Needs further investigation to determine if this can reasonably be done on Unixes without perf regressions.
            • Disabling hill climbing
              • This is a quick experiment to just measure the current perf effects of disabling hill climbing. Hill climbing adds some costs and it was seen that it doesn't help in several kinds of apps.
              • Gather some current perf data to understand the effects of disabling hill climbing. Perf in ASP.NET benchmarks appears to be mostly similar or slightly better. Perf metrics in a large internal service did not change, but with fewer worker threads on average.

            Some leftover work items are tracked in #52701.

            Metadata

            Metadata

            Type

            No type

            Projects

            No projects

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
              Skip to content

              Tracking issue for some thread pool experiments (.NET 8) #77665

              Description

              @kouvel

              This issue tracks some thread pool experiments/investigations that were proposed.

              • Polling for IO on worker threads
                • There can be some tradeoffs between using dedicated IO poller threads and polling for IO on worker threads. Some issues observed in some cases with dedicated IO pollers is the thread scheduling latency, difficulty of determining a number of IO pollers on machines of various sizes, and the extra thread hop in processing IO events.
                • Build a prototype for experimenting with and collect some performance data to understand the pros and cons. In progress.
                • Use one global epoll fd and determine an alternate mechanism to assiciate an IO event with a callback
                • Experiment with some strategies for polling for IO to balance the overhead, such as frequency of polling, batch sizes, etc.
              • Using the Windows thread pool
                • There can be some tradeoffs in using the Windows thread pool, it may be beneficial in cases where other components also use the Windows thread pool. The goal is to experiment with using it and collect some data to understand some of the tradeoffs.
                • Experiment with using the Windows thread pool in coreclr and measure perf. In progress.
                • Investigate regressions and determine if they can be reasonably fixed
              • Processing IO events at higher priority on Unixes
                • IO events are processed in the same order as global work items, so in cases where the global queues are heavily backed up, in-progress requests could be delayed by processing of new requests. The goal is mainly to try it out and to understand any perf regressions.
                • Build System.Net.Sockets against CoreLib, queue processing of IO events at high priority, and gather some perf data
                • Investigate regressions and determine if they can be reasonably fixed. Most of the ASP.NET benchmarks resulted in regressions. After some investigation and experimentation the regressions appeared to reduce in magnitude on some tests, but still there. Needs further investigation to determine if this can reasonably be done on Unixes without perf regressions.
              • Disabling hill climbing
                • This is a quick experiment to just measure the current perf effects of disabling hill climbing. Hill climbing adds some costs and it was seen that it doesn't help in several kinds of apps.
                • Gather some current perf data to understand the effects of disabling hill climbing. Perf in ASP.NET benchmarks appears to be mostly similar or slightly better. Perf metrics in a large internal service did not change, but with fewer worker threads on average.

              Some leftover work items are tracked in #52701.

              Metadata

              Metadata

              Type

              No type

              Projects

              No projects

                Relationships

                None yet

                Development

                No branches or pull requests

                Issue actions

                , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
                Skip to content

                Tracking issue for some thread pool experiments (.NET 8) #77665

                Description

                @kouvel

                This issue tracks some thread pool experiments/investigations that were proposed.

                • Polling for IO on worker threads
                  • There can be some tradeoffs between using dedicated IO poller threads and polling for IO on worker threads. Some issues observed in some cases with dedicated IO pollers is the thread scheduling latency, difficulty of determining a number of IO pollers on machines of various sizes, and the extra thread hop in processing IO events.
                  • Build a prototype for experimenting with and collect some performance data to understand the pros and cons. In progress.
                  • Use one global epoll fd and determine an alternate mechanism to assiciate an IO event with a callback
                  • Experiment with some strategies for polling for IO to balance the overhead, such as frequency of polling, batch sizes, etc.
                • Using the Windows thread pool
                  • There can be some tradeoffs in using the Windows thread pool, it may be beneficial in cases where other components also use the Windows thread pool. The goal is to experiment with using it and collect some data to understand some of the tradeoffs.
                  • Experiment with using the Windows thread pool in coreclr and measure perf. In progress.
                  • Investigate regressions and determine if they can be reasonably fixed
                • Processing IO events at higher priority on Unixes
                  • IO events are processed in the same order as global work items, so in cases where the global queues are heavily backed up, in-progress requests could be delayed by processing of new requests. The goal is mainly to try it out and to understand any perf regressions.
                  • Build System.Net.Sockets against CoreLib, queue processing of IO events at high priority, and gather some perf data
                  • Investigate regressions and determine if they can be reasonably fixed. Most of the ASP.NET benchmarks resulted in regressions. After some investigation and experimentation the regressions appeared to reduce in magnitude on some tests, but still there. Needs further investigation to determine if this can reasonably be done on Unixes without perf regressions.
                • Disabling hill climbing
                  • This is a quick experiment to just measure the current perf effects of disabling hill climbing. Hill climbing adds some costs and it was seen that it doesn't help in several kinds of apps.
                  • Gather some current perf data to understand the effects of disabling hill climbing. Perf in ASP.NET benchmarks appears to be mostly similar or slightly better. Perf metrics in a large internal service did not change, but with fewer worker threads on average.

                Some leftover work items are tracked in #52701.

                Metadata

                Metadata

                Type

                No type

                Projects

                No projects

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions