Pandoc: massive delay to call pandoc using the Windows Subsystem for Linux (WSL) or Bash for Windows

[mckennapsean]

Command to run: pandoc --version
Issue: command takes 20+ seconds to run
Operating System: Windows 10 Insider Build (but installing pandoc with a *.deb for Ubuntu 14.04)
Versions affected: pandoc v.1.18 - v.1.19.2.1

I have tested this on two modern Windows machines where I have installed pandoc on the Windows Subsystem for Linux (WSL). For both, just running pandoc to print version info results in 20+ seconds of runtime before it outputs version info, a significant delay.

If I revert back (using the provided .deb's) to v.1.17.2, then this does not occur and version info is printed instantly. So it seems something in v.1.18 (or the build of the deb) changed to result in this slowdown.

I have not tried compiling from source, but I am happy to dig into this a bit when I have time. I know development of pandoc 2.0 has significant changes, so let me know if I should try that out instead!

I am using an Insider Build for convenience, since Haskell and pandoc should be natively supported for WSL now. Timing-wise, this support will reach all of Windows users by the creators update schedule for April, woo hoo! However, I also had this same issue a few months ago on a regular Windows edition (so I know it isn't something that was introduced recently in the Insider builds). I noted another user who installed pandoc with WSL in #3332 - not sure if they had similar issues or not.

On the plus side, pandoc runs just fine in Windows without WSL. :)

[mb21]

I'm not sure we have anybody with a native windows install to test this outside of a VM... but if I may ask: what's the use case instead of just using the windows binary?

[mckennapsean]

The simple use-case is that I like having unix tools for doing processing, like in a bash script, which can be trickier to do on Windows for cross-platform support. I have seen others using pandoc this way (so it's not just me), like the link to the issue in this repo and in the BashOnWindows repository both linked above.

I am happy to test & compile anything if that could help narrow down the issue. Thanks!

[jgm]

Could you try the latest dev version from pandoc-nightly
https://github.com/pandoc-extras/pandoc-nightly/releases
to see if it behaves differently from 1.19.2? (The one marked amd64 is a linux build that should work for you.)

I can't think of any reason why you'd see this difference between versions.

If you have a chance to compile one of the affected versions from source, that would also give useful information.

[mckennapsean]

Thanks @jgm & @mb21 - I can confirm the same delays using both of the two most recent pandoc-nightly builds.

I tried compiling from source and hit some snags. Using stack, both the setup and installation (with a local ghc compiler) each failed due to a memory-allocation bug which has been fixed in fast-track Insider Builds (I'm on the slow-track). I also tried using cabal/ghc but received the error: "cabal: failed to parse output of 'ghc-pkg dump'", using cabal v.1.16.0 and ghc v.8.0.2. I may have missed some dependencies!

I downloaded a preview VM with the fast-track build to try the latest Windows build of WSL. I again confirmed the delays with pandoc when installed from the deb. I am in the process of compiling from source with stack now, will post results later if it works!

Also, I noticed that when I installed a local version of ghc v.8.0.2 then just calling the version info also runs _slow_. The delays I saw were nearly identical to the delays in pandoc, and this occurred on both my machine and the fresh VM. Printing version info in ghc worked normal & fast for both v.7.6 and v.7.10 on my machine, but not on v.8.0. Forgive my ignorance of pandoc, but is this possibly related / the reason behind the delays I saw in pandoc?

[jgm]

Good. Interesting. This doesn't sound like a pandoc-specific issue, then, though it would be good to figure it out. Maybe worth reporting to ghc developers, since they're probably more aware of the Windows subsystem issues relating to Haskell, and would be interested to hear about a difference between ghc versions?

[mckennapsean]

Indeed, I am wondering if it isn't just another issue with WSL too. Still awaiting on the compilation, so I will post results and let the ghc developers know about the issue too once I come up with steps for replication.

Feel free to close the issue, I can reopen if needed. It definitely seems like the problem lies elsewhere. Thanks!!

[mckennapsean]

Build failed (20 hours in, granted I only gave it part of a core). I have the output & log files still, but at a glance it looks like I may be missing a few dependencies. Now that I know to search for ghc, I have found a relevant issue on the BashForWindows repository for those looking to track this going forward:
https://github.com/Microsoft/BashOnWindows/issues/1671

Thanks all!