[markdown] Long init times on Win10

[gigadude]

Markdown freezes geany for about 10s on my Win10 system when starting up. I've verified that disabling/enabling markdown is what's causing the delay.

[codebrainz]

Is only only when Geany starts, or also when the plugin is enabled after startup too?

[gigadude]

After startup too, but only the first time (and apparently only for 1.29, 1.28 seems to be fine)

[codebrainz]

Does it take ~10 seconds if you start Geany without the plugin loaded and then using the Plugin Manager dialog enable it?

[eht16]

FTR: this is not specific to the Markdown plugin but rather for all plugins which use WebKitGTK on Windows. The same loading delay can be observed with the DevHelp plugin.

And it happens when the plugin is autoloaded at Geany startup as well as when the plugin is loaded initially in the Plugin Manager dialog.

@gigadude are you sure it doesn't happen with 1.28? I could bet I've seen this with 1.28 as well.
But never debugged it, just assuming it is related that loading all the rather huge WebKitGTK libraries (and dependencies like libicu) just needs some time. Though in theory it could also be some configuration issue.

[gigadude]

I've tried to repro a bunch of times on 1.28, haven't hit it. It happens 100% of the time on 1.29 (with the caveat that that's on a different machine). I'll try upgrading the 1.28 machine. FWIW I only started noticing this when I upgraded my work machine to 1.29.

[codebrainz]

But never debugged it, just assuming it is related that loading all the rather huge WebKitGTK libraries (and dependencies like libicu) just needs some time.

If this is the case, I would expect it to only be slow loading the first webkit-using plugin. What happens if you disable all (webkit-using) plugins, re-start Geany, load say Markdown plugin, then after the slow load, try and load another webkit plugin like WebHelper or DevHelp? Is the 2nd webkit plugin slow? If it's still slow on the 2nd plugin, I expect it's something besides normal DLL loading type stuff.

Also is it slow for just WebHelper alone? It was written by a different author than Markdown and DevHelp who knows webkitgtk better than me, and I believe it's also supporting a more recent version.

I will try to test it if I can get into a Windows, unless someone beats me to it.

[gigadude]

My very brief experiment was that loading/unloading was fast after the first time. Restarting Geany went back to slow.

[b4n]

@gigadude are you sure it doesn't happen with 1.28? I could bet I've seen this with 1.28 as well.
But never debugged it, just assuming it is related that loading all the rather huge WebKitGTK libraries (and dependencies like libicu) just needs some time. Though in theory it could also be some configuration issue.

Didn't we change how we create bundles in 1.29? Maybe the new libraries/options are different and slower to load or something? Do we pack the debugging symbols now maybe?

Also is it slow for just WebHelper alone? It was written by a different author than Markdown and DevHelp who knows webkitgtk better than me, and I believe it's also supporting a more recent version.

I don't deserve that credit, I learned the WebKit API for the occasion ;) And I don't think it supports recent WebKitGTK yet either. I planned to, but I don't think I ever finished it, did I?

[eht16]

Didn't we change how we create bundles in 1.29? Maybe the new libraries/options are different and slower to load or something? Do we pack the debugging symbols now maybe?

Obviously, though I thought it was already in 1.28. I don't think we are bundling debugging symbols though I didn't check it yet. Will try to do before the next release.

[eht16]

I could not find any reference to included debugging symbols or anything like that.
But with just built up2date Windows binaries, startup with Webkit plugins enabled feels a bit faster.

If anyone is curious to try: http://lists.geany.org/devel/2017-March/010203.html

[CeruleanSky]

Markdown was causing issues identical to what was mentioned above for me. I used ProcessHacker to look at the thread and frame stack causing the delay.

I noticed that when the problem occurs the program is also iterating through the fonts in the system very very slow locking up geany for several minutes until it is complete.

There were calls to functions in libfontconfig-1.dll on the stack frame of the thread read at 12% cpu usage(nearly 100% of one of 8 cores), and I saw handles opening and closing for fonts about once every second or several seconds for each font and I have 707 fonts though probably not all of them are applicable.

While it was happening reproducibly yesterday and the previous weeks on 1.30 and 1.31 and showed the same symptoms, it stopped doing so today(fortunately for me) and I could enable/disable the plugin without issue right now. If it reoccurs I'll provide the stack frame and perhaps it will help figure things out further.

[eht16]

Are you sure you experienced the slowiness on 1.31 ever?
For me, the 1.31 binaries started quite quickly, much faster than before. Though I didn't test and debug this issue in particular.
Anyway, this is(or has been) most probably a problem in one of the bundled libraries and not in our control.

[CeruleanSky]

I upgraded yesterday and took that opportunity to track down which plugin it was. I tested it with 1.30 and 1.31 before I went to sleep. I searched for the issue today and saw another person had an issue with markdown, tried to reproduce the stall, but today it was working fine. I'll add a stack trace if it reoccurs. Figured I'd still add what I could above since the next person to have the issue might use Process Hacker, double click on geany, then double click on the thread with the highest cpu usage, and create a stack frame trace which would confirm what I saw. But as you said, it is likely an issue with webkit/libfontconfig of which you only have so much control of.

Windows 7, geany 1.33 : activating markdown for Ist time caused Geany to be "Not responding" (freeze). Had to wait > 1 minute till it finished it's job (almost thought it's useless and a bug).
But after that, (re) activating markdown does not cause any freezes.