Thanks.

I have used Marko's excellent workaround at
http://groups.google.com/group/google-maps-api-for-flash/browse_thread/thread/52dc36c1a82ba119/b97415d349791572?hl=en&lnk=gst&q=lynxmap#b97415d349791572

Even with 200 markers, there is no memory/performance issues.

On Mar 5, 12:08 pm, pamela fox <[email protected]> wrote:
> Hilynxmap-
>
> We're looking into the memory issues you reported.
>
> - pamela
>
>
>
> On Sun, Feb 15, 2009 at 1:29 PM, [email protected] <[email protected]> wrote:
>
> > You can see the memory issue with pretty much any map that uses
> > markers.
> > It happens in the Marker Manager Demo
> >http://gmaps-utility-library-flash.googlecode.com/svn/trunk/examples/...
>
> > When you zoom into markers, the memory usage goes up and up, the bulk
> > of the memory is in the WrappableComponents.  This memory only
> > increases, even if overlays are removed.
>
> > This has become a real issue for my latest map, which allows the user
> > to cycle through a visual of thousands of markers (not all displayed
> > at the same time).  With each cycle, memory increases and increases,
> > even when markers are removed. Marker Instances do not decrease in
> > relation to markers actually removed.  In other words, they are not
> > disposed in memory. What ends up happening is the browser eventually
> > crashes on machines, say, with only 512MB memory.
>
> > HELP!  Any fixes to releasing memory??? Esp. with WrappableComponents?
>
> > thanks
>
> > On Feb 4, 4:35 pm, pamela fox <[email protected]> wrote:
> >> HiLynxmap-
>
> >> The wrappers are interfaces used inside the API to communicate between
> >> the client and the implementation library.
> >> It's possible that we're not cleaning up memory correctly, can you
> >> upload minimal code that replicates the issue?
>
> >> - pamela
>
> >> On Mon, Feb 2, 2009 at 3:59 PM, [email protected] <[email protected]> 
> >> wrote:
>
> >> > I have a question that might be pertinent to this thread--I'm working
> >> > on a map that might display a large number of markers.  In the
> >> > Profiler of FlexBuilder, I see that when this happens the largest
> >> > memory usage is by com.maps.google. wrappers.
>
> >> > Two questions:
> >> > 1. Can you explain the function of the wrappers.
> >> > 2. Even when I call map.clearOverlays(), the wrapper memory usage is
> >> > still there.  And then with the map with no markers, there still
> >> > remains hundreds of instances of markers, BaseEventDispatcher, and
> >> > Wrappable compoent, using quite a bit of memory.  And this is a simple
> >> > marker with no event listeners added yet!
>
> >> > Is there something fishy here with the memory usage for display/
> >> > clearing of markers??
>
> >> > cheers
> >> >lynxmap
>
> >> > On Jan 30, 9:56 am, pamela fox <[email protected]> wrote:
> >> >> I recommend using map.removeOverlay(overlayInstance) for removing
> >> >> markers, polys, etc.
>
> >> >> For removing a batch of markers, just push them onto an array, then
> >> >> later iterate through that array and call removeOverlay() on each
> >> >> marker.
>
> >> >> - pamela
>
> >> >> On Fri, Jan 30, 2009 at 8:12 AM, Oscar.Flash.Developer
>
> >> >> <[email protected]> wrote:
>
> >> >> > Found this in Pamela's Penguin Direction demo, it may be of use for
> >> >> > you too:
> >> >> > ...
> >> >> >  // Remove everything from map and add back the markers and polyline
> >> >> >  map.clearOverlays();
> >> >> > ...
>
> >> >> > Using that method you could clear the map, and then proceed as I
> >> >> > suggested earlier.
>
> --
> ----------------------------
> "if you can imagine it, you can do it"http://imagine-it.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Maps API For Flash" 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-api-for-flash?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to