We need to be optimizing for more than just the simple cases

by Michael S. Kaplan, published on 2007/03/13 05:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/03/13/1871045.aspx


We have to set our goals correctly.

The other day. Murray Sargent was asking some knowledgeable people (I'm not including myself in that assessment, as I was not added to the thread until it was several messages deep!):

I’m finding that NotePad on Vista is dramatically slower than on XP. I assume this is due to consideration of cool OpenType features. But if I’m only displaying ASCII with Courier New, a common scenario in viewing log files and the like, it makes no sense to invoke Uniscribe.

Basically a program should check to see if OT features are available that would be used for the text in question. If so, then use Uniscribe. Else go the fast route. In principle this approach could be pretty granular, e.g., down to the paragraph level.

There was a little back and forth as people did a combination of pointing out various potential sources of slowdown (DrawText in particular was called out as a big contributor to slowdowns here) and people asking for more data on how the slowdown was being defined. I myself pointed out some other inefficiencies such as the LPK connection (a feature that is of limited use with complex script support always on as it is in Vista) and Murray pointed out how RichEdit handles this better by not using Uniscribe in "non-complex" cases (though regular readers here might remember how that doesn't always work out, either!).

Then Peter Constable had what in my opinion was the best answer, one that I honestly wished I had thought to say first:

Actually, the real question is whether revising the line breaking in EDIT alone would fix things. Adding logic to detect the “non-complex” case to avoid Uniscribe leaves the bad perf behavior that Hindi, Arabic, Thai, etc. users have always had. If we fix what may be the sole problem, perhaps all users will finally have reasonable perf in Notepad.

You can see why I wished I had thought to say it first. I guess the geek in me got caught up in it all with everyone looking at the problem in the simpler terms of when it was fast and when it was slow and how to better draw the line.

My answer to people who want to turn off complex scripts in Notepad is usually a less polite version of Peter's response, though in my defense I am usually answering someone from the Perf team who is looking at the simple "Notepad with English text" scenario, and I am trying to get them to consider the rest of the world, while in this case my guard was not really up. It is much easier to defend a thing when it is under attack, is it not? :-)

In any case, Peter is completely right -- the best thing to do when looking at this type of issue is not to spend all the time trying to optimize for the non-complex, English-only, log file kind of scenario. Figuring out where the overall slowdowns are and then after that if there are still measurable performance issues trying to look at how to better manage the generic complex vs. non-complex text issue (including taking care of the issues that the RichEdit control in Windows misses these days!) is really the best way to go, for all languages that Windows supports....

 

This post brought to you by  (U+0959, a.k.a. DEVANAGARI LETTER KHHA)


# Mike Dimmick on 13 Mar 2007 7:14 AM:

If you're opening log files, you don't want to be using Notepad anyway because it will copy the entire file into contiguous RAM before beginning any rendering. Textpad (www.textpad.com) is much faster, even on XP.

I have a 12MB log file here that takes 18 seconds to load into Notepad. It loads in under a second in Textpad. I closed and reopened Notepad after the initial attempt to eliminate any cold-start effects, but there actually wasn't much difference in the time taken.

There's a serious case to be made here for carefully evaluating the controls you're using and developing a custom one if the standard controls can't meet the requirement. Notepad, as Raymond is fond of pointing out, is virtually a technology demo of the Edit control. The question is whether it should be, or whether the system should come with a decent editor.

# Michael S. Kaplan on 13 Mar 2007 8:19 AM:

Well, arguably it does -- Wordpad, the technology demo of the RichEdit control! :-)

# Dean Harding on 13 Mar 2007 6:28 PM:

I think notepad is fine for what it does, but Mike is right: you shouldn't be using it to open large log files.

Personally, I'm not a fan of 20MB log files at any rate, but I guess there's not much call for anything more complex... The event logging stuff in Windows is pretty cool (especially in Vista) but it's not really optimized for the megabytes-per-day that our servers generate ;)

# Serge Wautier on 14 Mar 2007 3:47 AM:

Speaking of Notepad as a Edit control wrapped into an exe, did things change in Vista? I mean these perf problems, do they occur in Notepad only or should we expect them in all our edit boxes ? (of course they rarely contain as much text as in Notepad, hence the problem shouldn't be that much scary).

# Michael S. Kaplan on 14 Mar 2007 6:53 AM:

Things did not change in Vista in this regard, no.


go to newer or older post, or back to index or month or day