File this one into the Mr. Murpy Loves Me category: I ran into a nasty issue yesterday with Markdown Monster, which is a WPF application. I got into trouble by innocently adding an SpellCheck.IsEnabled=true attribute to one of my text boxes on the Weblog Publishing form like this:

Figure 1 - WPF Spellchecking is easy to add with a simple property on a TextBox control

Why so slow???

But... on my dev machine there was a major problem: With that code in place the simple form that contains the spell check now took 3+ seconds to load. Say what?

So I tried to track this down. I removed the spell check code and immediately the form popped up instantly. Add the spell check back in - 3+ seconds load time.

Next, I tried this on another computer - a low end convertible no less - and guess what: No slowdown even with the spell check code in place. WTF?

A quick look at the Visual Studio Profiler Analysis on my machine quickly pointed me at InitializeComponent() block of code after which the Profiler disappears into native code, so the issue is something internal to WPF.

Dictionaries, Dictionaries

It turns out WPF spell checking uses Windows dictionaries and these dictionaries are globally referenced in the registry. When I took a look at the global dictionary registration key in the registry at:

Ugh! There were about 15 temporary dictionaries referenced in this section and sure enough these were the cause of my slow down.

Once I removed all the temp dictionaries and left just the legit Office dictionary my form now just pops again immediately.

The slowdown was caused by the errant dictionaries. I'm not sure why this is so incredibly slow. Given that the files referenced don't exist, there can't be any parsing happening. I also double checked to see that there weren't massive files in these folders which would make the look up really slow, but that's also not the case. Just having bad entries slows down the spell checker something fierce.

Temporary Dictionaries?

I also have no idea where these errant spell check dictionaries came from. I've been keeping an eye on this registry key and haven't seen temporary dictionaries returning. Clearly some application was writing out these files that subsequently get killed when my TMPFILES folder gets cleaned up by a daily scheduled task.

But unfortunately I have no idea which one. I'll keep an eye on this key and see if it returns after more use.

Moral of the Story

At the end of the day, if you should run into a problem with slow spell checking code - check your registry and make sure the dictionaries in use are legit.

It's definitely not something you are very likely to run into, but it's one of those strange edge cases that when they bite you, it takes a lot of time to track down. If you're unlucky enough to be bitten by this particular issue, hopefully you landed here and can fix your problem quickly - unlike me who wasted a few hours tracking this down.

This saved my bacon. I have an app that worked perfectly fine in Windows 7, but was unusably slow in Windows 10. I at one point timed it as taking 1 minute 40 seconds per spell-check enabled textbox, on a form that might have 30+ spell-check enabled textboxes. This was the problem, and after adding some kludgey registry-cleaning code, my app works in Win10 now, thanks!