Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • Files Files
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 397
    • Issues 397
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 61
    • Merge requests 61
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • FilesFiles
  • Merge requests
  • !601

file: Rate limit file date string generation

  • Review changes

  • Download
  • Patches
  • Plain diff
Closed Sebastian Keller requested to merge skeller/nautilus:date-string-cache into master Sep 21, 2020
  • Overview 18
  • Commits 2
  • Pipelines 5
  • Changes 2

The date string for a file used in the list view was getting regenerated for every frame when scrolling or resizing, which has become much slower with glib 2.66 due to changes in how it creates the local time zone. This resulted in a very low frame rate (2-3 fps on my machine).

This MR is a combination of António's rate limiting idea and my idea for caching the generated date strings. António's rate limiting was trying to rate limit time zone creation, but that did not entirely fix the issue, because there is no from_unix DateTime variant that accepts a custom time zone. My idea for caching the generated strings would require to monitor for timezone changes, which seems a bit of an overkill for such a thing. So instead use rate limiting on the date string generation, which still causes us to hit the slow path in the glib timezone generation, but now instead of every frame, we only hit it every 2 seconds.

If this is still causing stuttering and no glib improvements are in sight, maybe we need to add the timezone/day change monitor.

Related: glib#2204 (closed)

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: date-string-cache