Repository navigation
perf: parse rar and 7z listings faster - #548
liuwenhuan wants to merge 1 commit into
Conversation
1. Opening a 5-volume RAR archive with 3542 entries (38387 listing lines) took about 16 s of CPU in the GUI thread. 2. CliRarPlugin::readListLine() built and JIT-compiled the version-line regular expression for every line; it is now static and only matched until the version line is found. 3. Both plugins parsed every entry time with QDateTime::fromString(text, "yyyy-MM-dd hh:mm:ss"), whose format parser costs tens of microseconds per call. The time is now split into QDate/QTime when it has exactly that form (same local-time result); anything else still goes through fromString. Log: Open large RAR and 7z archives several times faster. Influence: 1. Parsing that listing (Qt 6.8.2): 5.2 s -> 0.58 s with TZ=Asia/Shanghai, 2.8 s -> 0.19 s in UTC; the same time for every entry. 2. A 3542-entry RAR archive loads in 0.9 s instead of 5.5 s; the file list shows the same modification times. perf: 加快 rar 和 7z 列表解析 1. 打开一个 5 卷、3542 个条目(38387 行列表输出)的 RAR 包,界面线程 要花约 16 秒 CPU。 2. CliRarPlugin::readListLine() 每读一行都重新创建并 JIT 编译版本行的正则, 改为静态对象,且只在找到版本行之前匹配。 3. 两个插件都用 QDateTime::fromString(text, "yyyy-MM-dd hh:mm:ss") 解析每个 条目的时间,格式解析每次要几十微秒。时间严格是这个格式时改为拆成 QDate/QTime(本地时间结果相同),其他情况仍走 fromString。 Log: 打开大型 RAR、7z 包快数倍。 Influence: 1. 解析上述列表(Qt 6.8.2):上海时区 5.2 秒 -> 0.58 秒,UTC 2.8 秒 -> 0.19 秒, 每个条目的时间一致。 2. 3542 个条目的 RAR 包加载从 5.5 秒降到 0.9 秒,文件列表显示的修改时间不变。
Reviewer's GuideImplementationAdd a fast path for strictly formatted listing timestamps while retaining the existing parser as a fallback in both plugins.
Make the RAR version-line regular expression static and match it only while parsing the header states.
Make the 7z version-line regular expression static to avoid reconstructing it for every listing line.
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
CLA Assistant Lite bot: You can retrigger this bot by commenting recheck in this Pull Request |
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Opening a 5-volume RAR archive with 3542 entries (38387 lines of
unrar vt -voutput) took about 16 s of CPU in the GUI thread. unrar itself writes the listing in 0.2 s. Almost all of the time goes to two things:CliRarPlugin::readListLine()built and JIT-compiled the version-lineQRegularExpressionfor every line. It is nowstaticand only matched until the version line is found.QDateTime::fromString(text, "yyyy-MM-dd hh:mm:ss"), whose format parser costs tens of microseconds per call. The time is now split intoQDate/QTimewhen it has exactly that form, which gives the same local time. Anything else still goes throughfromString. The 7z fractional-seconds handling on master is unchanged and runs before this.Measured with a small program that replays the plugin's per-line work on that real listing (Qt 6.8.2):
Every entry gets the same time in all variants.
In the application, a 3542-entry RAR (the same paths, empty files) loads in 0.9 s instead of 5.5 s, and the file list shows the same modification times. That was measured in a VM on deepin-compressor 6.5.32.3 with this change backported. This PR compiles on master (6.5.40).
打开一个 3542 个条目的 RAR 包时,界面线程大部分时间花在每行重新编译正则和每个条目调用
QDateTime::fromString上。本 PR 把正则改为静态对象,时间严格是yyyy-MM-dd hh:mm:ss格式时直接拆成QDate/QTime,结果不变。列表解析在上海时区从 5.2 秒降到 0.58 秒。Summary by Sourcery
Enhancements: