IE6 vs FF: Huge memory usage differences
SalvadorDiaz
I'm developping a rather large GWT application and I recently noticed
a HUGE difference between memory usage on IE6 and FF:
Just loading the application (arriving at the entry point) makes
firefox go from 42 000 kB to 44 292 kB (rather normal I guess)
The problem is with IE6: from about:blank to my entry point makes
IE6's memory usage go from 54 000 kB to a whopping 223 456 kB
Is this a normal pattern? I mean, the huge difference in memory usage
on both browsers.
Could it be some widget's fault ? Like ImageBundle for instance? (I
make extensive ImageBundle usage)
I wish I could give you some more thorough details, but right now my
application is just too big for me to be able to single out the
culprit easily and I'm just beginning to explore the issue.
Any help will be really appreciated. Thanks in advance
Luc Claes
If you are using ImageBundles, you should have a look at the
dimensions (width * height) of the generated .png files.
In our experience, large 'area' ImageBundles involve incredibly high
memory consumption in IE.
You will have to group your images in ImageBundles in such a manner
that the generated w * h remains low.
HTH,
Luc
Bruce Johnson
SalvadorDiaz
Bruce: I'm willing to try anything, in our project it has become the
top priority to bring down memory usage on IE6 so let me know what I
can do and I'll report my findings as soon as possible.
On 11 oct, 01:02, "Bruce Johnson" <br...@google.com> wrote:
> Optimizing layout automatically is something we've been debating adding to
> ImageBundle. If you would be willing to try out a few thing manually and
> report your findings, it could really help us justify prioritizing such a
> feature.
>
Bruce Johnson
multiple image bundles instead of a few large ones such that each
image bundle contains image of roughly the same height. ImageBundle
lays out images horizontally, so height discrepancies within the same
image bundle would cause extra blank space to be added to the image,
which could be a problem if you have one really tall image and many
short ones in the same image bundle.
Another general approach would be to simply check for any particularly
tall images and ensure that you don't include them in an image bundle.
If that makes a big difference, that will be yet more evidence that
IE is doing something wasteful with all the blankness in the bundled
image.
Reinier Zwitserloot
space. For example, let's say there's one 100x500 image, and then 500
10x10 images. GWT would layer these into a single imagebundle with
size 5100x500. However, it could theoretically also fit the same thing
into a 200x500 image, saving a factor 25.5 in pixel space (as I
understand it, there's a direct relationship between pixelsize and IE
memory issues). End of IE memory problem in that particular scenario.
It would be non-trivial during compilation to find a reasonably
efficient 'packing' given any set of images (it would in fact be NP-
complete to try to find the best packing, if my rusty analysis skills
are correct), but I think in practice a much simpler algorithm that
just tries to fold new images into existing nooks and crannies without
looking forward for better packing results will already take care of a
lot of IE leakage issues, won' be -too- hard to write, and shouldn't
take too long to compile. Some sort of caching mechanism that realizes
the image sources for a given bundle haven't changed, so that it
doesn't need to go and repack, would definitely be handy as compile
time is already a dicey issue. Another complication would be that the
Generator needs to generate code that needs to know an extra
parameter. Right now for any image it needs 3 numbers (width, height,
xOffset). With this it needs yOffset as well. I haven't looked at the
ImageBundle generator (or even at the generator mechanism in general)
but I assume a yOffset is easily added.
A bit hypocritical for me to make all these suggestions while having
no intention to submit a patch, though :/
On Oct 11, 8:43 am, "Bruce Johnson" <br...@google.com> wrote:
> It would be a useful experiment to see what happens if you create
> multiple image bundles instead of a few large ones such that each
> image bundle contains image of roughly the same height. ImageBundle
> lays out images horizontally, so height discrepancies within the same
> image bundle would cause extra blank space to be added to the image,
> which could be a problem if you have one really tall image and many
> short ones in the same image bundle.
>
> Another general approach would be to simply check for any particularly
> tall images and ensure that you don't include them in an image bundle.
> If that makes a big difference, that will be yet more evidence that
> IE is doing something wasteful with all the blankness in the bundled
> image.
>
SalvadorDiaz
have 2 ImageBundles, one with all of our "final" images, and one with
"temp" images (for the sake of minimizing the number of server round
trips; as this seems to be the logic behind the ImageBundle). So our
entire application makes extensive use of these 2 imageBundles, the
"final" one being 13563px*148px (283kB) and the temporary one being
2491*421 (144kB).
So here's what I'm going to do:
First I'll make sure to get rid of the tallest images in my bundles
and I'll check the differences in mem usage.
Then I'll split these into several ImageBundles each one containing
images of roughly the same height and again report the differences in
mem usage.
One more thing though, that I think it's worth mentioning: IE keeps
eating up memory and never releases it and we think we just found the
culprit:
-In order to "simplify" the calls to the imageBundle, we declare in it
the following:" public static final Images INSTANCE = (Images)
GWT.create(Images.class); " so developers can just invoke it in any
class.
On FF this doesn't arise any issues, but IE doesn't seem to garbage
collect widgets no longer attached to the DOM tree when they use the
image bundle like that. If instead we create a factory, with the
following static method "public static Images getImages(){return
(Images)GWT.create(Images.class);}" the memory gets actually freed.
Ok, back to experimenting now, I'll be reporting my findings
throughout the day (It's 10am here in Paris by the way)
On Oct 11, 8:43 am, "Bruce Johnson" <br...@google.com> wrote:
> It would be a useful experiment to see what happens if you create
> multiple image bundles instead of a few large ones such that each
> image bundle contains image of roughly the same height. ImageBundle
> lays out images horizontally, so height discrepancies within the same
> image bundle would cause extra blank space to be added to the image,
> which could be a problem if you have one really tall image and many
> short ones in the same image bundle.
>
> Another general approach would be to simply check for any particularly
> tall images and ensure that you don't include them in an image bundle.
> If that makes a big difference, that will be yet more evidence that
> IE is doing something wasteful with all the blankness in the bundled
> image.
>
David Given
> So our
> entire application makes extensive use of these 2 imageBundles, the
> "final" one being 13563px*148px (283kB) and the temporary one being
> 2491*421 (144kB).
I hate to say it, but that 13563x148 image isn't 283kB. That's the
compressed size. It contains about two million pixels, which means that
uncompressed (the way the browser's probably going to store it
internally) it'll occupy about 4 to 8 megabytes, depending on the pixel
format.
--
David Given
d...@cowlark.com
SalvadorDiaz
First some specs:
- Original image bundles:
* Images: 13563px*148px, 283kB
* CustomImages: 2491px*421px, 144kB
- Modified image bundles (I got rid of the tallest of the images in
the ImageBundles and now I create them using a normal Image widget,
ie: new Image("someUrl"))
* Images:11727px*82px, 202kB
* CustomImages: 1867px*93px, 37kB
And now my findings with IE (as far as we're concerned there's no
issue with FF):
- Using the original image bundles:
*From about:blank to entryPoint the memory goes from 14 076kB to
222 100kB (I tried this 3 times and the 3 measurements came pretty
close)
-Using the modified image bundles:
*From about:blank to entryPoint: 14 076kb -> 139 200kB (I tried
this 3 times and the 3 measurements came pretty close)
We're now pretty sure ImageBundles are causing these huge performance
issues, but I'll test grouping images by height and report my findings
as well.
SalvadorDiaz
maybe IE doesn't store pngs in compressed format internally, but FF
seems to do it: there are roughly 15 visible images when you load the
page and they're all created with that wide image bundle, so if FF
were to store them 15 times uncompressed it wouldn't report such a low
memory usage (from about:blank to my site memory usage on FF goes from
25 Megs to 45 Megs)
Can anyone confirm this compressed/uncompressed differences between
browsers?
Salvador
rusty
someone even more hypocritical than you, since I've never contributed
a single line of GWT code. Even a relatively inefficient algorithm
would make a difference.
@Salvador that's a pretty good pickup. I never would have made the
connection between large (pixel large, not bytes large) and memory use
in IE. I will have to do some testing tomorrow with some of our apps
and see if I experience the same thing...I will let you know (our main
image is 2605x92).
Rob Coops
Fred Sauer
In other words, is the IE internal uncompressed image size different if the original image has a different pixel depth?
--
Fred Sauer
fr...@allen-sauer.com
Bruce Johnson
instead of PNGs, if you aren't relying on transparency. I don't know
if IE decompresses JPGs into a more space-efficient memory layout than
for PNGs, but it's probably worth trying. I doubt it would be tough to
patch.
On 10/11/07, Rajeev Dayal <rda...@google.com> wrote:
> Sure, I will take a look at this at the start of next week.
SalvadorDiaz
-I grouped images by height in different ImageBundles so now I have
the following ImageBundles instead of the 2 huge ones. These are the
resultant bundles:
* 1288px*10px, 2kB
* 1115px*22px, 12kB
* 4643px*41px, 33kB
* 3808px*50px, 38kB
* 823px*75px, 32kB
*3091px*93px, 86kB
These bundles don't include images that were simply too tall. These
are the images that were included in the original huge ImageBundles
that now are standalone images:
* 531px*117px, 4kB
* 114px*148px, 29kB
* 624px*421px, 94kB
And there's an increased memory usage performance using the grouped-by-
height bundles (compared to the first 2 approaches):
*From about:blank tom entryPoint: 14 048kB -> 93 000kB (that's
the mean value of 5 measurements)
Well, I think we learned an important lesson regarding ImageBundles
and IE6 so from now on we will be extracareful when using them.
SalvadorDiaz
But maybe it is a good idea to create separate tag interfaces for each
type of ImageBundle, like PngBundle and JpegBundle or something like
that and then create the modified version of the bundle generator to
handle the jpegBundle creation.
Thanks anyway.
Salvador
On Oct 11, 5:08 pm, "Bruce Johnson" <br...@google.com> wrote:
> It may also help to patch the image bundle generator to create JPGs
> instead of PNGs, if you aren't relying on transparency. I don't know
> if IE decompresses JPGs into a more space-efficient memory layout than
> for PNGs, but it's probably worth trying. I doubt it would be tough to
> patch.
>
> On 10/11/07, Rajeev Dayal <rda...@google.com> wrote:
>
> > Sure, I will take a look at this at the start of next week.
>
> > On 10/10/07, Bruce Johnson <br...@google.com> wrote:
> > > Optimizing layout automatically is something we've been debating adding to
> > ImageBundle. If you would be willing to try out a few thing manually and
> > report your findings, it could really help us justify prioritizing such a
> > feature.
>
Bruce Johnson
> Well, I think we learned an important lesson regarding ImageBundles
> and IE6 so from now on we will be extracareful when using them.
Hopefully you can also unlearn most of the lessons in another GWT
release or two. We want image bundles to "just work" efficiently
without your having to think about it, and by implementing some of the
things we discussed above and a few other tweaks, we think it can be a
no-brainer to use image bundles without surprises.
Bruce Johnson
> But maybe it is a good idea to create separate tag interfaces for each
> type of ImageBundle, like PngBundle and JpegBundle or something like
> that and then create the modified version of the bundle generator to
> handle the jpegBundle creation.
We've discussed making the determination of the bundled image type
automatic, based on the actual set of images you use. So, if you only
used JPGs, then you'd a JPG bundled image, and so on.
SalvadorDiaz
what I wrote about the way we use the ImageBundles:
Does declaring the following in the image bundle (called Images) will
stop widgets using images from this ImageBundle from being garbage-
collected on IE ?:
public static final Images INSTANCE = (Images)
GWT.create(Images.class);
Because it appears so (bonus question: where can I found more about
the garbage collector, I've heard that you kind of reimplementated it
but I'm not sure where)
Thank you very much,
Salvador
On Oct 11, 5:26 pm, "Bruce Johnson" <br...@google.com> wrote:
Bruce Johnson
to keep the image bundle around. Rajeev or Joel might have some useful
thoughts about it. IIRC, the image bundle itself doesn't actually
maintain any references to the bundled image file, so I am a bit
surprised about that behavior. It may be that IE doesn't unload loaded
images at all, in case you reference them again in another <img>
element. I'm really just speculating.
-- Bruce
P.S. We didn't implement our own GC. It's just that the UI API design
won't allow cycle-based leaks to occur unless you explicitly cause on
via JSNI.
On 10/11/07, SalvadorDiaz <diaz.s...@gmail.com> wrote:
>
Rajeev Dayal
Yes, this is definitely doable. We'll just have to agree on when it is appropriate to have this as an output format. As you mentioned, it is not appropriate when one of the images uses transparency. However, we wouldn't want to use this output format if it would cause a quality loss in the images. So maybe it is only appropriate to have JPG as the output format if all of the input images are JPGs as well? I'm just speculating here; this is something that I'll have to look into.
With regard to the unloading of loaded images in IE6:
How large is your image bundle image (i.e. what are the dimensions, and what is the size in bytes)?
There is potentially an issue with the reclaiming of memory used by image bundle PNG images in IE. We are making use of the DirectXAlphaImageLoader in order to properly display PNG images, and there have been reported cases where it seems to hold on to the memory even after the image is removed from the page. I don't think it has anything to do with holding a static reference to the ImageBundle. If possible, could you run a test where you do you keep a static instance, and see if the same problem occurs?
Thanks,
Rajeev
David Given
Hash: SHA1
Rajeev Dayal wrote:
[...]
> Yes, this is definitely doable. We'll just have to agree on when it is
> appropriate to have this as an output format. As you mentioned, it is not
> appropriate when one of the images uses transparency. However, we wouldn't
> want to use this output format if it would cause a quality loss in the
> images. So maybe it is only appropriate to have JPG as the output format if
> all of the input images are JPGs as well? I'm just speculating here; this is
> something that I'll have to look into.
JPG is lossy, which means that in order to convert JPG to JPG you have to
decode it (losing data) and then reencode it again (losing more data). What's
more, JPG artifacts tend to confuse the JPG compression system --- because
they tend to introduce sharp edges and ringing --- which exacerbates the
problem. This generally means, it's unwise to decompress a JPG and then
recompress it again, particularly if it's line art.
That said, you can normally get away with it a couple of times if you're
careful with the settings. I don't know what ImageBundle uses to create JPG
bundles, but somewhere there should be a setting for the compression quality,
typically measured in percentage points. Here are some sample images:
http://gate.cowlark.com/~dg/original.png
http://gate.cowlark.com/~dg/1-gen-85.jpg
http://gate.cowlark.com/~dg/2-gen-85.jpg
http://gate.cowlark.com/~dg/1-gen-70.jpg
http://gate.cowlark.com/~dg/2-gen-70.jpg
1-gen, 2-gen are first and second generation copies at 85% and 70%
respectively. The noise is quite clear on the 70% copies, and if you look
carefully you can see it on the second generation 85% copy. Nothing
unmanageable, but you'll need to micromanage the settings.
- --
┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ───────────────────
│
│ "There does not now, nor will there ever, exist a programming language in
│ which it is the least bit hard to write bad programs." --- Flon's Axiom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHDqqpf9E0noFvlzgRAjIqAJ4uFW1UNKVsvX/4WjAjM1+qKN666ACeJ46B
RpadlHCqoVBS+0bM6TVIBng=
=N1Ep
-----END PGP SIGNATURE-----
Reinier Zwitserloot
efforts from Salvador and David don't get lost in the chatter.
http://code.google.com/p/google-web-toolkit/issues/detail?id=1765
On Oct 12, 12:58 am, David Given <d...@cowlark.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rajeev Dayal wrote:
>
> [...]
>
> > Yes, this is definitely doable. We'll just have to agree on when it is
> > appropriate to have this as an output format. As you mentioned, it is not
> > appropriate when one of the images uses transparency. However, we wouldn't
> > want to use this output format if it would cause a quality loss in the
> > images. So maybe it is only appropriate to have JPG as the output format if
> > all of the input images are JPGs as well? I'm just speculating here; this is
> > something that I'll have to look into.
>
> JPG is lossy, which means that in order to convert JPG to JPG you have to
> decode it (losing data) and then reencode it again (losing more data). What's
> more, JPG artifacts tend to confuse the JPG compression system --- because
> they tend to introduce sharp edges and ringing --- which exacerbates the
> problem. This generally means, it's unwise to decompress a JPG and then
> recompress it again, particularly if it's line art.
>
> That said, you can normally get away with it a couple of times if you're
> careful with the settings. I don't know what ImageBundle uses to create JPG
> bundles, but somewhere there should be a setting for the compression quality,
> typically measured in percentage points. Here are some sample images:
>
>
> 1-gen, 2-gen are first and second generation copies at 85% and 70%
> respectively. The noise is quite clear on the 70% copies, and if you look
> carefully you can see it on the second generation 85% copy. Nothing
> unmanageable, but you'll need to micromanage the settings.
>
> - --
> ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───http://www.cowlark.com───────────────────
> │
> │ "There does not now, nor will there ever, exist a programming language in
> │ which it is the least bit hard to write bad programs." --- Flon's Axiom
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org