Skip to content

Experimental "short-lived lookup maps" feature needs profiling #28

@SoraKagami

Description

@SoraKagami

The new (optional and experimental) "short-lived lookup maps during some render/search/tree operations" feature needs proper testing and benchmarking to determine whether to keep it, discard it, or leave to users to decide.

This feature was added with the v0.7.6 update 9c3cf2d.

ChatGPT's suggested benchmark

Best practical way: benchmark real user actions, not synthetic micro-timings. This option probably affects repeated tree lookups, so differences may only show with large bookmark sets.

Suggested test setup

Use the same SBM build, same bookmark set, same browser profile, and compare only this setting:

Optimisation_TempBookmarkTreeMaps = enabledOptimisation_TempBookmarkTreeMaps = disabled

After changing the setting, fully reload the extension manager tab.

What to benchmark

Use a folder structure with many bookmarks/folders, ideally your real bookmarks or a copied test profile.

Test these actions several times with the option enabled, then disabled:

  1. Open SBM.
  2. Switch between large folders.
  3. Search with Limit Search to Current Folder & Subfolders enabled.
  4. Search globally.
  5. Expand/collapse large Library tree branches.
  6. Multi-select a large range.
  7. Drag/drop multiple items.
  8. Open Options popup, change setting, close popup.

Simple manual timing method

In Brave/Chromium:

  1. Open SBM.

  2. Press F12 to open DevTools.

  3. Go to Performance.

  4. Click Record.

  5. Perform one specific action, for example a large search.

  6. Stop recording.

  7. Compare:

    • scripting time
    • rendering time
    • total duration
    • long tasks
    • noticeable UI delay

Repeat the same action 3–5 times with the setting enabled and disabled. Ignore the first run if it is much slower, because the browser may still be warming up/caching.

Memory comparison

Use Chrome/Brave Task Manager:

Shift + Esc

Look at the SBM extension tab/extension process memory before and after repeated operations.

Suggested process:

  1. Reload SBM.
  2. Wait 10 seconds.
  3. Record memory.
  4. Perform the same search/tree actions 10–20 times.
  5. Wait 10 seconds.
  6. Record memory again.
  7. Repeat with the option disabled.

Because the optimisation uses temporary maps, memory should rise briefly during operations but should not keep growing after repeated use. If memory keeps climbing and never settles, that would be suspicious.

What results would matter

I would consider the optimisation worth keeping enabled if:

  • large searches feel smoother, or
  • repeated folder/tree operations show lower scripting time, and
  • memory does not keep increasing over time.

I would disable/remove it if:

  • no measurable improvement appears, or
  • any selection/tree behavior becomes inconsistent, or
  • memory grows after repeated operations.

My suggested benchmark checklist

Setting: enabled / disabledOpen SBM time:Large folder switch:Current-folder search:Global search:Expand large tree:Collapse large tree:Multi-select 100 items:Drag/drop 50 items:Memory at idle:Memory after 20 operations:Any UI glitches:

For this specific optimisation, I would trust behavior correctness more than small performance gains. If the difference is not obvious on your real bookmark set, it may not be worth keeping enabled long-term.

Metadata

Metadata

Assignees

Labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions