Would it make sense to change the default optimizations to favor speed?

[R-Goc]

Currently optimizations are set to favor size. However, changing that to favor speed over size makes little difference on binary size, which goes from 16.7MB to 18.7MB. For this increase in size, there is an increase in performance of around 5-10% according to my testing on a PDF document using bench.

[kjk]

2 MB is quite a lot. Majority of binary size are fonts, not the code.

But sure, I'm not terribly opposed to it.

Can you share the actual benchmark numbers?

A good start would be to add ReleaseFast configuration to enabled building both for comparison.

[R-Goc]

Optimized for speed:

Finished (in 6292.73 ms): ..\..\Downloads\248966-Optimization-Reference-Manual-V1-050.pdf

Default:

Finished (in 6884.38 ms): ..\..\Downloads\248966-Optimization-Reference-Manual-V1-050.pdf

[kjk]

One run on one file is not enough to make a decision.

[GitHubRulesOK]

Hmm I am usure why the time above is so slow
out of interest I downloaded that nominal file into this very old (more than one decade) and slow 32bit 4 GB device.

The show logs result says most time spent loading prior session but in addition that file was fast.

CreateControllerForEngineOrFile: 'C:\Users\lez\Downloads\248966-Optimization-Reference-Manual-V1-050.pdf', 895 pages
LoadDocument: 149.42 ms, 895 pages for 'C:\Users\lez\Downloads\248966-Optimization-Reference-Manual-V1-050.pdf'
DisplayModel::BuildPagesInfo started
DisplayModel::BuildPagesInfo took 0.10 ms

If I clear history its even faster

LoadSettings('C:\Users\lez\AppData\Local\SumatraPDF\SumatraPDF-settings.txt') took 0.54 ms
CreateToolbar: setting toolbar font size to 18 (default size: 12)
CreateControllerForEngineOrFile: 'C:\Users\lez\Downloads\248966-Optimization-Reference-Manual-V1-050.pdf', 895 pages
LoadDocument: 136.22 ms, 895 pages for 'C:\Users\lez\Downloads\248966-Optimization-Reference-Manual-V1-050.pdf'
DisplayModel::BuildPagesInfo started
DisplayModel::BuildPagesInfo took 0.16 ms
FileWatcherSubscribe: not starting a file watcher thread due to 32-bit miscompilation
NewPageDestinationMupdf: path='Ch01_Vol1.pdf', dest='nameddest=G7717'
FileWatcherSubscribe: not starting a file watcher thread due to 32-bit miscompilation
DeleteStaleFiles: dir: 'C:\Users\lez\AppData\Local\SumatraPDF-data', gIsPreRelaseBuild: 1, ver: prerel-3.6.16578-32
currTabIdx: 0

[R-Goc]

That is interesting, I'll give an example log of the whole thing:

out\rel64\SumatraPDF.exe -bench ..\..\Downloads\248966-Optimization-Reference-Manual-V1-050.pdf -console

https://gist.github.com/R-Goc/a9b8e238acc382a9580741fdb81ef918
I'm not sure if we're comparing the same thing.
Load is indeed way faster than on your machine.
Not exactly sure why it exits with 1. It always shows that for me.
I tried using hyperfine, but for whatever reason I'm getting quite a large overhead, over 1s per run, and the output is not being discarded, which is weird. Not sure how output is being handled when -console is passed, but it seems non standard.

[GitHubRulesOK]

Ahh right using Bench as shown
I get Finished (in 22847.95 ms) but if speed reading 2 novels in 22 seconds is the aim another one second is not a problem for my eyes.

[R-Goc]

This is a fairly easy to render document, but when scrolling quickly on image heavy documents there could be a difference which you can feel. I have a 1100 page document which takes around 25 seconds on bench. On an older machine if you were to scroll 50-100 pages you would probably feel that.

[R-Goc]

I can't pipe the output either so not sure how to easily get a good benchmark

[GitHubRulesOK]

You can redirect to txt nual-V1-050.pdf >tryit.txt but that's adding a text writing delay
however my steam boat says Finished (in 21621.22 ms): so shaved one second off

[R-Goc]

There is some variance in the runs, which is why i wanted to use hyperfine to get easy statistics, but can't figure it out.

[R-Goc]

On the heavy document I am seeing anywhere between 2 and 4 seconds. But that is not scientific at all. Why isn't it just using stdout? or rather the file is getting created but the console is still getting spammed

[R-Goc]

Wait what is passed to the pipe is just

ParseFlags: cmdLine: 'out\rel64\SumatraPDF.exe  -bench ..\..\Downloads\248966-Optimization-Reference-Manual-V1-050.pdf -console '
ParseFlags: argName: '-bench', arg: 51
ParseFlags: argName: '-console', arg: 15
Starting SumatraPDF 3.6, GetCommandLineW(): 'out\rel64\SumatraPDF.exe  -bench ..\..\Downloads\248966-Optimization-Reference-Manual-V1-050.pdf -console ', flags.install: 0, flags.uninstall: 0
  isInstaller: 0
  isUninstaller: 0, flags.uninstaller: 0
DetectExternalViewer: cmd 298, 'C:\Windows\explorer.exe' "%d"
DetectExternalViewer: cmd 302, 'C:\Program Files\Adobe\Acrobat DC\Acrobat\Acrobat.exe' /A page=%p "%1"
DetectExternalViewer: cmd 307, 'C:\Windows\hh.exe'
LoadSettings('C:\Users\rysza\bin\sumatrapdf\out\rel64\SumatraPDF-settings.txt') took 0.24 ms