IE7 a RAM Hog

Submitted by kebernet on Mon, 06/13/2005 - 08:46

Tagged:

Software

Adam Stiles points out that IE7's tabs will chew memory...

Perhaps the trickiest decision MS was whether to break compatibility with 3rd-party IE toolbars. Currently, IE toolbars are "tied" one toolbar to one IE window. But when done right, tabbed browsers save memory compared to single-window browsers because tabs share toolbars. Use the RoboForm toolbar for example. In NetCaptor, you can have 20 tabs open and one RoboForm toolbar - but 20 IE windows would require 20 RoboForm toolbars. After MS announced IE7 would have tabs, I expected to hear about changes to the add-on APIs to allow IE7 tabs so share toolbar instances. I never considered the possibility that each IE7 tab would have its own copy of 3rd party toolbars. But that's the direction Microsoft has taken. What's the problem with that approach? Every time you open a new browser tab (which tabbed browser users do much more frequently than single-window browser users), you have to create new instances of any 3rd-party bars. Ouch. Opening a folder of 25 Favorites in tabs? You get 25 RoboForm toolbars, and use much more memory and resources than necessary.

Boy, Mozilla is going to start looking like the Lean and Mean browser soon :P

Add new comment

Comments

RE: IE7 a RAM Hog

Submitted by atrox (not verified) on Mon, 06/13/2005 - 09:32.

You know, aside from Firefox "Web Developer" I have never used a "toolbar" anyway. Its a tangent really but what in the hell is with all this toolbary stuff anyway? Oh nevermind, you have to have a toolbar or two (the Google toobar for example) to make IE even usable, I forgot. (To block popups, etc.)

RE: IE7 a RAM Hog

Submitted by Shmooze (not verified) on Mon, 06/13/2005 - 09:50.

I totally agree - all toolbars do is eat up desktop space. I even keep Web Developer off now and just enable it when I want to use it, rather than have it sucking on my precious desktop space. MS does confuse me sometimes though. For being an 800lb gorilla they seem to go through great pains for compatability. Aren't all these toolbar things free? Would it be that bad to break them and make the authors rebuild them to work with an improved product?

RE: IE7 a RAM Hog

Submitted by cooper (not verified) on Mon, 06/13/2005 - 11:19.

I have actually had some discussions with Josh about backwards compatibility in general. It is funny, though, how obsessed people seem to be with it sometimes. Our context was always about the java runtime. Sun has corporate customers that will bitch to the heavens if JDK 1.5 wouldn't run some ancient 1.0 app seamlessly, so they end up with these archaic GUI libraries and components that were poorly designed the first time around getting rolled forward, rather than just saying "If you need 1.1, run a 1.1 JRE". At least with Java -- certainly when coupled with JWS -- you can install as many JRE's as you want on one machine. MSIE still has to have that "It's part of the OS" shit, mostly for legal purposes at this point, so you still can't have different versions of MSIE installed. God forbid some company has an internal explorer bar or toolbar than IE7 minght break in the quest to not suck, but whaddya gonna do.

RE: IE7 a RAM Hog

Submitted by atrox (not verified) on Mon, 06/13/2005 - 16:06.

Yeah the whole Java thing is silly. Even in the open source world and not at Sun. I was reading a Junit discussion: whereas Junit 4 it seems will use annotations, people were bitching that they wanted a lot of the stuff in 4 but could not use it because that will require JDK 1.5. Get the hell over it, if you want new stuff, use a new JDK. Its just not that goddamn hard to refactor stuff (at least not server side and or junit type stuff, I cant speak for GUI stuff), its more a matter of DOING IT rather than BITCHING as opposed to the actually difficulty.

RE: IE7 a RAM Hog

Submitted by cooper (not verified) on Mon, 06/13/2005 - 19:56.

Even in the open source world and not at Sun

Well, I will say this: Java's JAR file format has a big advantage over (almost) everything out there in terms of libraries: CLASSPATH gives you the effect of static compiles. I can't count the number of times I have had to deal with conflicting Perl modules, Python libraries or (more and more) Mono mappings. The fact that when you download a Java app, aside from maybe a specific JDK, it comes with everything it needs to run is a big win. On Windows, of course, you end up with that "Just one Java plug in and just one JAR mapping", but if you use WebStart to distribute your app, you can use any specific JRE version you need and they all run seamlessly. Of course, there is still the problem with the applet-style network security model for JWS apps. And yeah, I really think JDK 1.5 suffered from a serious problem with NOT adding keywords. Old rant here, but

public annotation Foo

would be a lot better than

public @interface Foo

And god knows when I "Tigered up" my code, I had to replace a lot more java.util.Enumerations named "enum" than anything named "annotation".

RE: IE7 a RAM Hog

Submitted by atrox (not verified) on Tue, 06/14/2005 - 09:25.

@interface True. Much of the annotation stuff, which I am just starting to actually use, would be much clearer if it used the same type of language facility that is already in place and everyone already knows. New keywords with new meanings. As to not doing that because of a fear of affecting code, yes the "enum" thing happened and yes the "annotation" thing could happen, but back to the point of what I meant about JUST DO IT, it takes a few minues to scrub THOUSANDS OF FILES AND MANY LINES OF CODE for "enum", its just not that big of a deal. Now if you have libraries that you dont control the source to declaring "annotation" and "enum" then you have to get someone else on the ball, but still really should not be that big of a deal. New keywords would have been hella better for annotations.