Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
evolution
evolution
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 190
    • Issues 190
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 1
    • Merge Requests 1
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GNOME
  • evolutionevolution
  • Issues
  • #965

Closed
Open
Opened Jun 02, 2020 by Jeff Fortin Tam@jfft

Multi-threaded searching for speedier local search performance with big slow folders

This ticket is a bit of a spiritual successor to issue #853 and issue #821 (closed).

In #821 (comment 754868) I observed a CPU usage pattern that seems to strongly suggest that Evolution's local search is single-threaded, where very little disk I/O happens and only one CPU core is used at 100% at any given time:

Screenshot_from_2020-03-30_14-39-51

Having a multi-threaded search (even if it's something basic like looking at the list of messages to be searched and dividing it up equally into search domains) would allow dividing the "time the user spends waiting for search" by 4, 8, 16 or more on the typical modern computer. Even on a silly cheap dual-core CPU (hell, even a RaspberryPi is quad-core!) it would probably at least halve the search time, which is already a significant improvement.

For a 20-thousand-messages scenario, it would be the difference between waiting 10-20 seconds for results (which is problematic for being able to "try" various searches, as a user) vs waiting barely 2-3 seconds even for "full body text search".

Obviously this ticket is not about a "bug" on fire, it's an enhancement request, in the hope that someone seeing this wishes to try something on that front. But I really do think it might be the biggest speed improvement opportunity in Evolution, and it would be a killer feature! It would be fast-enough that no progressbar would be needed.

Edited Jun 02, 2020 by Jeff Fortin Tam
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: GNOME/evolution#965