No problem Berry - I'm actually pleased to finally touch base with
somebody who has some experience working on a similar issue as I have
so running a test is the least I can do!

Nothing crashed, though IE8 did crash when I closed it - which I
wouldn't really worry about.

It's really a pain to know if the garbage-collector was going to come
around or not in Chrome in FF - but I usually assume that I catch it
when you see a huge peak in memory usage and then it drops down.

I had explored this issue a lot a when I was developing on V2 about 2
years ago  - browsers have changed a lot since then - and I strayed
away from using CANVAS because it seemed like Garbage Collectors had a
harder time reclaiming memory used on CANVAS objects after a redraw
compared to SVG objects.

Also, I figured SVG objects would use less memory than CANVAS objects
for especially large Polygons - since they are Vector based as opposed
to bitmap based.

I noted that V3 creates SVG and VML for their Polygon objects - but
they create a series of Viewboxes - one for each 256 x 256 grid on the
map.  I guess that makes sense since the map will only draw the
portions of the SVG/VML that it needs (and from a purely design
principle it seems to fit in with the rendering of everything else on
the map ) - but I think it also could be a source of the leaking,
since the implementation has to create events for each square grid
viewpoint and constantly remove and create new ones as the map is
dragged around.

I'll be leaving for the weekend in a few hours - when I leave today
I'll clear out all my cache and make sure I am loading your SVG
version test and let that run over the weekend, so we'll have several
days of usage to look at on Monday.

At this point I've completely given up on using Google's Polygon
objects (at least in the state they are in now) - but I'm happy to
continue our conversation on custom implementations of this.

On Dec 3, 12:50 pm, bratliff <[email protected]> wrote:
> On Dec 3, 3:33 pm, John Mick <[email protected]> wrote:
>
>
>
>
>
>
>
>
>
> > Okay so here is what I observed on your PolyCluster test:
>
> > At 5:00PM EST on 12/2/2010:
> >      -Firefox was using about 52,000K of Memory (This number would
> > increase quickly into a low 100,000K then lower itself back down to
> > around 52,000K)
> >      -Google Chrome was using about 35,000K of Memory (This number was
> > also increasing and then lowering itself back down to around 35,000K)
> >      -Internet Explorer 8 was using about 33,504K of Memory (Unlike
> > Firefox and Chrome, this memory usage only fluctuated slighting around
> > 33,504K)
>
> > At 10:25AM EST on 12/3/2010:
> >      -Firefox was using about 168,000K of Memory (This number would
> > increase very quickly to as high as 303,000K then reduce itself back
> > down to a little higher than 168,000K)
> >      -Google Chrome was using 1,242,840K of Memory and steadily
> > increasing - I never observed this to go back down
> >      -Internet Explorer 8 was using only 43,000K of Memory and was
> > still only slightly fluctuating around that number
>
> > It looks like the VML implementation in PolyCluster seems to work
> > better than the SVG implementation - as far as memory usage goes.
> > Unfortunately by now it has become obvious to me that I won't be able
> > to use the Google Maps V3 Polygon objects and it seems that I'll have
> > to continue to use a proprietary SVG/VML solution to keep my real-time
> > application running.
>
> > If I didn't have a requirement of this application remaining open in a
> > web browser 24 hours a day, 7 days a week - these memory leaking
> > issues wouldn't be such a huge concern of mine.
>
> Thanks John,
>
> At least nothing crashed, correct ?
>
> Garbage collection is performed "Just-in-time".  Perhaps you caught
> Firefox & Chrome close to their high water marks.  I will try to
> figure out what I might be doing to leave debris.
>
> Internally, the paths are stored as arrays rather than as objects.  It
> is machine friendly but not human friendly.  Perhaps the little
> {x:,y:} objects in the application itself are causing fragmentation of
> the memory pool.  I will experiment.
>
> If you are successful, please let me know what you did.  I will be
> happy to share some of my code with you too.  For what it is worth, I
> am using CANVAS for Firefox & Chrome if neither "setClick()" nor
> "setCover()" is called to establish event listeners.  Otherwise, SVG
> is used.
>
> I have made a change to the test case to force the use of SVG where
> appropriate.  Be sure to clear your cache.
>
>    http://www.polylib.us/polycluster/fixleak
>
> Let me know if it helps.  Thanks again,
>
> Berry

-- 
You received this message because you are subscribed to the Google Groups 
"Google Maps JavaScript API v3" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-maps-js-api-v3?hl=en.

Reply via email to