• menu delay - pinned tasbar menu folders - 10 second delay or more

    From Marion@3:633/280.2 to All on Sat May 24 04:47:09 2025
    I saw the other thread about the start menu delay, where I tried valiantly
    when Windows 10 came out to get the left & right start menus to work.

    I gave up.

    I simply created a menu folder mirroring my installation hierarchy:
    c:\menu\{archivers,browsers,cleaners,databases,editors,finances,etc.}
    And put the shortcuts in that cascaded pull-out accordion menu.

    This has worked for years, and the beauty of this ingenious design is that nothing pollutes it. It only has what I put into it. It's perfect.

    Well... almost perfect.

    Sometimes, for whatever reason, the second or third pullout is dog slow. Usually it's the third pullout that gets dog slow though.
    C:\menu\editors\{audio,barcode,codec,etc.}

    Why?

    What would slow down the display as much as 10 seconds of that third menu?
    How do I prevent that from happening?

    Nothing is overtly running in the background when this happens (ThatIKO).

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: BWH Usenet Archive (https://usenet.blueworldho (3:633/280.2@fidonet)
  • From Paul@3:633/280.2 to All on Sat May 24 06:15:47 2025
    On Fri, 5/23/2025 2:47 PM, Marion wrote:
    I saw the other thread about the start menu delay, where I tried valiantly when Windows 10 came out to get the left & right start menus to work.

    I gave up.

    I simply created a menu folder mirroring my installation hierarchy:
    c:\menu\{archivers,browsers,cleaners,databases,editors,finances,etc.}
    And put the shortcuts in that cascaded pull-out accordion menu.

    This has worked for years, and the beauty of this ingenious design is that nothing pollutes it. It only has what I put into it. It's perfect.

    Well... almost perfect.

    Sometimes, for whatever reason, the second or third pullout is dog slow. Usually it's the third pullout that gets dog slow though.
    C:\menu\editors\{audio,barcode,codec,etc.}

    Why?

    What would slow down the display as much as 10 seconds of that third menu? How do I prevent that from happening?

    Nothing is overtly running in the background when this happens (ThatIKO).


    Have you watched with Process Explorer (better than Task Manager)
    and with Process Monitor, for hints ?

    When an event is easily reproduced, that gives you time to tune your
    monitoring of it.

    Paul



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Marion@3:633/280.2 to All on Sat May 24 07:15:48 2025
    On Fri, 23 May 2025 16:15:47 -0400, Paul wrote :


    What would slow down the display as much as 10 seconds of that third menu? >> How do I prevent that from happening?

    Nothing is overtly running in the background when this happens (ThatIKO).


    Have you watched with Process Explorer (better than Task Manager)
    and with Process Monitor, for hints ?

    When an event is easily reproduced, that gives you time to tune your monitoring of it.

    I don't think it's that as this has been happening for years.
    Nothing is crunching in the background & nothing else is slow.

    I think it's almost as if Windows has an expiry date for shortcuts.
    Or maybe an expiry for the thumbnails? Dunno.

    But it just happened moments ago.
    Not for all of the folders and subfolders.

    Just one or two.
    And the second time they show up fast.

    Just the first time.
    It's as if Windows needs to rebuild the thumbnails or sumphin'

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: BWH Usenet Archive (https://usenet.blueworldho (3:633/280.2@fidonet)
  • From Hank@3:633/280.2 to All on Sat May 24 07:18:48 2025
    Marion wrote to us on Fri, 23 May 2025 18:47:09 -0000 (UTC):

    I saw the other thread about the start menu delay, where I tried valiantly when Windows 10 came out to get the left & right start menus to work.

    I gave up.

    I simply created a menu folder mirroring my installation hierarchy:
    c:\menu\{archivers,browsers,cleaners,databases,editors,finances,etc.}
    And put the shortcuts in that cascaded pull-out accordion menu.

    This has worked for years, and the beauty of this ingenious design is that nothing pollutes it. It only has what I put into it. It's perfect.

    Well... almost perfect.

    Sometimes, for whatever reason, the second or third pullout is dog slow. Usually it's the third pullout that gets dog slow though.
    C:\menu\editors\{audio,barcode,codec,etc.}

    Why?

    What would slow down the display as much as 10 seconds of that third menu? How do I prevent that from happening?

    Nothing is overtly running in the background when this happens (ThatIKO).

    It sounds like you've created a very organized and effective custom menu system, and it's frustrating when it occasionally bogs down. The "dog slow" performance, especially on the second or third pullout, points to a few potential culprits. Let's break down why this might be happening and how
    you can prevent it.

    Why Your Menu Might Be Slowing Down
    Icon Loading:

    The biggest suspect. Each shortcut in your menu has an associated icon.
    When Windows displays a menu, it needs to load all the icons for the items
    in that menu. If you have many shortcuts in a subfolder (like C:\menu\editors\audio), and those icons are high-resolution, embedded
    within large executables, or are pointing to network locations (even if the actual program isn't on the network), this can cause significant delays. Corrupt Icon Cache: Windows maintains an icon cache to speed up icon
    loading. If this cache becomes corrupted or too large, it can actually slow things down instead of speeding them up.
    Number of Items:

    While you've organized them well, a very large number of shortcuts within a single subfolder can still contribute to slowdowns. The more items Windows
    has to process and display, the longer it takes.
    Shortcut Target Resolution:

    When you hover over a menu item, Windows might be doing a quick check to
    ensure the target of the shortcut still exists and is accessible. If a
    shortcut points to a program on a drive that's temporarily offline, a
    network share that's slow to respond, or a removable drive that's not
    currently plugged in, it could introduce a delay.
    Antivirus/Indexing Software:

    Even if "nothing is overtly running," your antivirus software or Windows
    Search Indexer could be silently scanning the directory or the target files
    of your shortcuts when the menu is accessed. This is especially true if
    you've recently added new shortcuts or if the software is performing a scheduled background scan.
    Disk I/O and Fragmentation:

    While less likely to cause a 10-second delay on its own for menu items, if
    the hard drive where your shortcuts and their target programs reside is
    heavily fragmented, it could contribute to slower access times.
    Shell Extensions:

    Less common for simple shortcuts, but sometimes third-party shell
    extensions (programs that integrate with Windows Explorer's context menus
    or file previews) can interfere and cause slowdowns when navigating directories.
    How to Prevent the Slowdown
    Here's a step-by-step approach to diagnose and fix the issue:

    Focus on Icon Optimization (Most Likely Solution):

    Custom Icons: For shortcuts in your slowest menus, consider assigning
    custom, smaller-sized icons (e.g., 32×32 or 48×48 pixels) that are stored
    as .ico files directly within your C:\menu structure (or a dedicated C:\menu\icons subfolder). This ensures Windows doesn't have to extract
    icons from large executables every time.
    To do this: Right-click the shortcut > Properties > Change Icon... >
    Browse... and select your custom .ico file.
    Clear and Rebuild the Icon Cache: This is a classic fix for icon-related slowdowns.
    Close all open folders and programs.
    Open Task Manager (Ctrl+Shift+Esc).
    Go to the "Details" tab.
    Find explorer.exe, select it, and click "End task."
    In Task Manager, go to File > Run new task, type cmd, and press Enter.
    In the Command Prompt, type the following commands one by one, pressing
    Enter after each:
    cd /d %userprofile%\AppData\Local
    del IconCache.db /a
    exit
    In Task Manager, go to File > Run new task, type explorer.exe, and press
    Enter.
    This will restart Explorer and force Windows to rebuild the icon cache.
    Reduce Number of Items (If Applicable):

    If a single subfolder has an enormous number of shortcuts (e.g., hundreds), consider breaking it down further into more specific sub-categories. For example, C:\menu\editors\audio could become C:\menu\editors\audio\editors
    and C:\menu\editors\audio\converters, etc.
    Check Shortcut Targets:

    Manually test each shortcut in the slowest menu. If any of them point to network locations, removable drives, or non-existent files, either correct
    them or remove them. Even if the program itself isn't on a network, a
    shortcut target could be.
    Temporarily Disable Antivirus/Indexing (for testing):

    Caution: Only do this briefly for testing purposes. Temporarily disable
    your antivirus software's real-time scanning and the Windows Search
    service. Then, try accessing your slow menu. If the performance improves significantly, you'll need to configure your antivirus to exclude the
    C:\menu folder and its subfolders from real-time scanning. For Windows
    Search, you can adjust its indexing options.
    Disk Maintenance:

    Run a disk defragmenter (if you're on an HDD) or ensure your SSD is
    properly trimmed. This is less likely to be the primary cause for menu slowdowns but good practice.
    Clean Up Shell Extensions:

    Tools like ShellExView (from NirSoft) can help you see all installed shell extensions. You can disable them one by one to see if any are causing conflicts. This is a more advanced step and should be done cautiously.
    Consider a Different Menu Launcher (Alternative, Not a Fix for the Root
    Cause):

    While you love your current system, if you continue to experience issues, a dedicated third-party application launcher might handle icon caching and display more efficiently. However, this deviates from your "nothing
    pollutes it" philosophy.

    By systematically addressing these points, starting with icon optimization
    and cache management, you should be able to identify and eliminate the
    cause of your "dog slow" menu performance.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: NUO - News.Usenet.Ovh (3:633/280.2@fidonet)
  • From Paul@3:633/280.2 to All on Sat May 24 07:36:59 2025
    On Fri, 5/23/2025 5:15 PM, Marion wrote:
    On Fri, 23 May 2025 16:15:47 -0400, Paul wrote :


    What would slow down the display as much as 10 seconds of that third menu? >>> How do I prevent that from happening?

    Nothing is overtly running in the background when this happens (ThatIKO). >>>

    Have you watched with Process Explorer (better than Task Manager)
    and with Process Monitor, for hints ?

    When an event is easily reproduced, that gives you time to tune your
    monitoring of it.

    I don't think it's that as this has been happening for years.
    Nothing is crunching in the background & nothing else is slow.

    I think it's almost as if Windows has an expiry date for shortcuts.
    Or maybe an expiry for the thumbnails? Dunno.

    But it just happened moments ago.
    Not for all of the folders and subfolders.

    Just one or two.
    And the second time they show up fast.

    Just the first time.
    It's as if Windows needs to rebuild the thumbnails or sumphin'


    We know that some parts of that process, are lightning fast.

    The menu might open faster, if it ignored the cache and
    rendered brand new items.

    Maybe it had always used WebView for rendering ? If you watch in
    Task Manager, does anything WebView related use CPU ?

    https://www.reddit.com/r/Windows10/comments/bewvps/start_menu_gets_its_own_process_and_a_performance/

    Paul

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)