Designing for Add-on Performance

re: Designing for Add-on Performance

orz — Fri, 04 Apr 2008 22:20:39 GMT

Very interesting, but totally fails compared to FUEL. Why are we mucking around with the registry at all? Can't this be a simpler API?

re: Designing for Add-on Performance

simple fix — Sat, 05 Apr 2008 00:30:03 GMT

As you noted in your comments:

"since add-ons execute in the context of the UI thread"

Well, this is an easy fix!

When initializing the addon, if there is an update to be made, a new thread should be spawned...

A "readyState" flag on the addon should be updated when the updates are complete, but until they are done, either run the addon in the last stable version, or disable it until the addon is updated.

Or finally, let the developer choose when they want to do the update, and have it run on demand...

e.g. User loads google, they don't need an update,... user loads page with the "ACME services running", a check is done for updates... if found, informs user of updates, and gives _THE_USER_ the choice as to when to update.

re: Designing for Add-on Performance

Chad — Sat, 05 Apr 2008 01:37:39 GMT

Off topic, but ....

Could you please remove the horrific clicking sound every time you click a link? that'd be great.

thanks

re: Designing for Add-on Performance

EricLaw [MSFT] — Sat, 05 Apr 2008 01:59:04 GMT

@Chad: For other applications that host the WebOC, simply use FEATURE_DISABLE_NAVIGATION_SOUNDS

http://msdn2.microsoft.com/en-us/library/ms537169(VS.85).aspx

For IE, just use START> CONTROL> Sounds>Sounds> SoundEvents and change the "Start Navigation" sound to blank.

The Delight is in the Details

Ben 'Cerbera' Millard — Sat, 05 Apr 2008 09:31:58 GMT

Great to see this level of detail on IE Blog, and with links to even more detail. :)

EricLaw, your link didn't work. Likely reason is an overly cautious comment parser.

re: Designing for Add-on Performance

Andrei Moraru — Sat, 05 Apr 2008 11:02:37 GMT

I guess there will be much more work in future to make the addons creation and optimization easier.

Because now it doesn't look very attractive. At least to me.

Anyways, thanks for sharing some helpful information.

re: Designing for Add-on Performance

EricLaw [MSFT] — Sat, 05 Apr 2008 18:48:51 GMT

@Ben, you can either copy/paste the full URL, or use this one:

http://msdn2.microsoft.com/en-us/library/ms537169.aspx

re: Designing for Add-on Performance

Amy — Sat, 05 Apr 2008 21:20:00 GMT

Ok this is a bit offtopic but can one of you IE developers tell me how i can get the natural width and height of an image? This should be easy using C++ and COM? Is there some QI i can do to get this information? I am using a really slow hack for this and its is the main reason my Add-on is slow.

re: Designing for Add-on Performance

user — Sat, 05 Apr 2008 21:21:28 GMT

When IE (7 and 8) starts up, e.g. before the menu bar appear, if I paste some words to the URL box or search box, the final text shown in these boxes will be concated with the words I pasted and the original text/"grey google" text.

E.g. I paste abc into search box during start up, which using Google as the seacher. The text becomes "abcGoogle"

I am using WinXP ENU SP2

Rob^_^

Rob Parsons — Sat, 05 Apr 2008 23:48:56 GMT

Calling home for updates should be a user-iniated process that is accessed by clicking a button and not as a setting option as in the Google Toolbar.

Toolbar Layout Hijacks

Rob Parsons — Sun, 06 Apr 2008 00:09:25 GMT

The Google, Yahoo and Live toolbars all over-write the IE7ToolbarLayout in the registry on startup and negate user preferences. The Google and Yahoo toolbars can be fixed by disabling the Satellite BHO with the Add-ons Manager, but the Live Toolbar refuses to honour User Preferences.

Google Beta 5 has corrected this problem, but of coarse without auto-matic updates many users are left in confusion. It would be prudent to advise these Toolbar vendors directly about Best Practices as Public Feedback options do not cater for Technical explanations.

Please pass your recommendations on to the Live, Yahoo and Google toolbar developers.

re: Designing for Add-on Performance

Tino Zijdel — Sun, 06 Apr 2008 02:09:12 GMT

This blogpost merely illustrates that creating add-ons for IE is far to complex. Basically a good API should take care of such hassle as having to deal with update-checking, registry-storage etcetera.

Also there should be a simple, light-weight add-on model where normal scripting can be used to perform simple tasks in/on opened windows/tabs.

If IE would have had such light-weight scripting-based add-on model we would have had good and helpful webdevelopment tools already years ago and it would certainly have helpt the adoption of IE as a serieus development platform.

re: Designing for Add-on Performance

Joe — Sun, 06 Apr 2008 03:42:50 GMT

Tino, as described AT LENGTH here and elsewhere, there are many ways to write IE extensions, including Javascript. See, for instance, http://blogs.msdn.com/ie/archive/2005/09/06/461675.aspx

Part of the problem with powerful extension models is that careless or sloppy addon developers will misuse them. This post is an attempt to help educate those developers who choose to write native code extensions.

re: Designing for Add-on Performance

anonymous — Sun, 06 Apr 2008 09:53:36 GMT

Speaking of add-ons, one of the most horrible addons that nearly kills IE performance has been the Live Search Club Toolbar. While I know that comes from a different team at MS, it would be really nice if you guys could impart and share your knowledge also with those ppl. No other addon I've known slows down IE as much as the Live Search Club toolbar.

re: Designing for Add-on Performance

IEdude — Sun, 06 Apr 2008 10:48:37 GMT

Add-on is cool, more ActiveX(MS Internet Control) support is better !

Current add-on model should be changed

Assaf — Sun, 06 Apr 2008 12:04:00 GMT

The current add-on model for OS components (for example IE and explorer), that is native code running in the context of the host is outdated and no longer fits the requirements of the Internet era.

The problems with these add-ons are:

- An add-on has the same security restrictions as the host - that is, almost no restrictions. He can write files, change registry settings, etc..

- As noted above, an add-on can affect performance of the host

- And most important, no accountability - the add-on can change host behaviour without being accountable - you don't know which extension or add-on creates a specific behaviour, problem, performance degredation, etc...

This model fits if the add-ons are all written by the host creator, or if the host isn't some critical component, but on critical components such as the operating system's browser or file manager, nothing should be allowed to disrupt the usual operation, and anything added should be easily removed.

I've stumbled upon a Microsoft Research project, Singularity, which tries to address some of these problems. It's an interesting concept, but it'll probably take many years to implement this approach fully.

re: Designing for Add-on Performance

Joe — Sun, 06 Apr 2008 20:04:04 GMT

@assaf: It's a nice idea, but unfortunately, pretty unworkable. Users prefer to have powerful extensibility available within their browsers, and any artificial restrictions which are introduced more than likely will compel the user to use another browser which offers them more power.

Singularity is a nice toy, but Joel Spolsky has pointed out the problems with sandboxes pretty nicely (e.g. here: http://www.joelonsoftware.com/items/2007/09/18.html).

IE8 Designing for Add-on Performance

News — Sun, 06 Apr 2008 22:02:14 GMT

As we worked towards the recent release of Internet Explorer 8 Beta 1, the IE team focused hard on performance

re: Designing for Add-on Performance

demon — Sun, 06 Apr 2008 23:55:32 GMT

@chad - i like that clicking sound

@anyone else - all i know is, ie 8 looks and feels just about the same as ie 7. granted, i hardly used it cuz everytime i went to utube, it would serve me up a lovely fatal error and crash. ie 8 def has some flash issues, at least on my end.

re: Designing for Add-on Performance

Tino Zijdel — Mon, 07 Apr 2008 00:29:17 GMT

Joe: if you have ever tried to create an extension that is just a bit more non-trivial than adding a context-menu item, like adding a toolbar or sidepane that can interact with the current loaded document and receives events on navigation, you would know that it is just not that simple.

Even the most trivial examples require fiddling in the registry and thus are a pain for the writer to create and distribute and for the user to install and administer.

For instance: I have (JS-based) code that can be used to 'live edit' CSS on any webpage that works in IE and would love to make an add-on out of it with a toolbar and a sidepane that shows the CSS. Fact is that that last part is pretty hard to achieve when you've got no experience in that kind of programming and from what I've seen in MSDN documentation and examples it is quite a steep learning-curve to master that kind of programming.

So basically it requires me to learn special skills that I otherwise have no actual use for or I would have to outsource that particular part which makes it more difficult to provide my add-on for free and also maintain it myself.

Продам коттедж в Никольском (Салтыковка)

nexalencype — Mon, 07 Apr 2008 05:33:45 GMT

Продается дом в поселке Николькое. 2км от МКАД по Горьковскому шоссе. Дом 400 метров.

Участок 10 соток. Ландшафтный дизайн. Все коммуникации, отопление. Гостевой дом.

Дом строился "Под себя"

подробнее: [url=http://realty.skeeve.ru/sell/nikolskoe.html]http://realty.skeeve.ru/sell/nikolskoe.html[/url]

$700 000. 8-926-203-77-81 Алексей

re: Designing for Add-on Performance

Mike Dimmick — Mon, 07 Apr 2008 12:51:18 GMT

On the subject of the registry, I'd just like to add that the guidance to reduce registry use does *not* mean you should start doing everything in configuration files instead. The registry is many times more efficient than a text-based configuration file, for small to medium sizes of data.

The people using RegFlushKey for synchronising different instances of the same control are WRONG WRONG WRONG because the OS does not need to go back to the disk. Registry updates in one process are immediately seen in all other processes. The OS caches recently-used parts of the registry data in physical memory. The cost of opening a key and reading a value comes from the fact that the registry API is down in kernel mode and a kernel mode transition takes millions of cycles. It takes longer to open a key with a longer key path because it has to start at the top of the tree and follow pointers all the way down (some of which may not be in memory already and need to be paged in from disk). It also has to check security every time you open a key, so keeping keys open can be a good idea.

If you have many values you need to check in the same key, and you know their names, you can use RegQueryMultipleValues to retrieve them all at once. If you can, structure your registry storage to have lots of values under one key, not lots of keys with few values.

If you really want to share data between different instances of the same control in different processes, consider using shared memory (CreateFileMapping with the first parameter INVALID_HANDLE_VALUE, to get a pagefile-backed area, and naming the object so you can repeat the process for each one, then MapViewOfFile to actually access it).

re: Designing for Add-on Performance

Phil — Mon, 07 Apr 2008 19:12:09 GMT

"The registry is many times more efficient than a text-based configuration file, for small to medium sizes of data."

I'd disagree. How many people have trashed their Windows installs due to altering the wrong key somehow or making a typo? If you mess up a separate config file, you've only hosed that app.

The Registry is a horrendous mess of keys and values. A new vision needs to be created for future Windows - Registry is simply too unwieldy and cumbersome.

re: Designing for Add-on Performance

Anonymous — Tue, 08 Apr 2008 03:26:30 GMT

@Phil: You aren't really disagreeing with what he said, you're making an entirely different point.

"A is more efficient than B" doesn't necessarily mean "A is better than B overall". Although it does mean that "B is not better than A in every aspect".

We're not talking about manually editing the registry anyway.

re: Designing for Add-on Performance

Eli — Wed, 09 Apr 2008 01:46:06 GMT

Windows has lots of low-level optimizations for making the registry as fast as possible and keeps most of it in RAM, unfortunately. This is mainly because lots of third party apps think accessing the registry is free. It probably is way more effecient than reading a text configuration file, but that shouldn't matter because you're supposed to be caching your settings either way. :)

There's lots of advantages to having a registry, if there's issues they should be fixed as opposed to throwing the whole thing out.

Don't Break Existing IE Extensibility

Clinton Gallagher — Wed, 09 Apr 2008 04:13:44 GMT

The use of Task Panes in IE has been under utilized not to mention hardly documented at all. An href can for example target="_search" and load a web form in a Task Pane that will open on the left side of IE.

At the moment IE8 does is not backward compatible and does not support _search Task Pane which I have used often and hope to encourage its further development and documentation.

In fact I think the Task Pane should become a significant aspect of IE extensibility --BUT-- at least don't break what's already supported.

re: Designing for Add-on Performance

ping — Wed, 09 Apr 2008 20:35:13 GMT

disabling and enabling add-ons requires IE restart. Would be nice to not restart IE everytime we want to disable add-ons and IE user can easily turn it on without the Manage add-on UI showing up. If that is possible

re: Designing for Add-on Performance

Confused — Thu, 10 Apr 2008 16:38:20 GMT

With regard to the add-on update check, why don't you recommend just using version numbers for add-ons? Even with asynchronous update check, based on the way you describe it, it'll slow down the connection for a while. A two or three byte version code would be so much faster to check, and could be done either way without causing a noticeable slow down (assuming the person doesn't have an excessive amount of add-ons).

After finding a newer version, then give the user the option of "updating now" or later with an add-on management button (opens management window which lists add-ons, green for up-to-date, red for out-of-date, and has check boxes for the red ones with an "update selected add-ons" button somewhere visible in the management window). This would let people with slow connections update later when they're not going to need to be online and doing things. As far as I'm aware not even FireFox has such a usable add-on management system, this could be an area you could surpass them in right now.

But eh, you guys can take the advice or leave it, makes little difference to me.

re: Designing for Add-on Performance

Geld Lenen — Fri, 11 Apr 2008 17:05:56 GMT

This sure will speed things up, like Steve Souders mentioned in his post. Keep up the great work!

IE8 at Add-On Con in Mountain View

IEBlog — Wed, 03 Dec 2008 03:11:01 GMT

A few of the startups building browser Add-Ons have organized the first ever Add-On Con , to take place

Common Issues in Assessing Browser Performance

IEBlog — Sat, 24 Jan 2009 02:03:24 GMT

I’m Christian Stockwell, a Program Manager on the IE team focused on browser performance. Measuring the

Common Issues in Assessing Browser Performance

Блог команды разработчиков Internet Explorer 8 — Tue, 03 Feb 2009 15:18:27 GMT

Проблемы при оценке производительности браузеров Добрый день! Меня зовут Кристиан Стоквелл (Christian

Проблемы при оценке производительности браузеров

Блог команды разработчиков Internet Explorer 8 — Tue, 03 Feb 2009 15:21:13 GMT

Добрый день! Меня зовут Кристиан Стоквелл (Christian Stockwell) и я возглавляю команду разработчиков

애드온 성능 설계

IE8 팀 블로그 — Fri, 20 Mar 2009 10:23:04 GMT

  최근 Internet Explorer 8 Beta 1 출시를 위해 개발중인 IE 팀은 성능에 심혈을 기울이고 있습니다. IE  향상을 위한 노력의 일환으로 실행한