Hi Ankur, An application size of 3MB sounds extremely large. Is that gzipped or uncompressed? Also, how large is your codebase?
I would imagine that the runAsync feature would have given you a huge boost in reducing the initial download size of your application. You mentioned that you broke down the compiled code into multiple script tags - this doesn't sound like the result of using the runAsync feature, but rather a manual attempt at breaking your code into smaller chunks. Did you use the runAsync feature to break down the compiled code into smaller chunks, or use a different approach? For what it's worth, 700 MB of memory entirely used up by your GWT application is an immensely high number. Are you sure that this is only when your application is running in the browser? If so, there are major hot spots where you are either instantiating way too many objects at a time or leaking major amounts of memory as you navigate from one part of the application to the next. The problem with profiling memory for an Ajax application is that there aren't very many robust tools that can be used reliably to find and fix hot spots. For the time being, a rudimentary way of analyzing where memory usage blows up and where memory leaks are occurring would be to monitor your system task manager as you navigate through your application. When you see memory usage boost up, you know that you've at least found the neighbourhood of code where the culprit(s) is hiding. Sorry I can't be of more help, but hopefully this gives you a start to track down where your code is blowing up in memory usage and cut down the initial download size. Hope that helps, -Sumit Chandel On Sat, Jul 25, 2009 at 12:22 PM, ankur jain <[email protected]> wrote: > hi > > thanks for the reply.But we checked its not due to image bundle.We are > using a proper workaround that is mensioned in the issue. > > Actully main problem what we are facind is due to the listeners.And it > being very difficut to profile the application in debug mode bcoz most of > the refrences are held by the callback objects. > > I m totally confused. > > > regards > ankur > > On Thu, Jul 23, 2009 at 3:17 PM, David <[email protected]> wrote: > >> >> Hi Ankur, >> >> Could it be that you are using ImageBundle in your application ? We >> had similar issues when using ImageBundle, even though we only had a >> very small collection of images. >> >> http://code.google.com/p/google-web-toolkit/issues/detail?id=3573 >> >> >> David >> >> On Wed, Jul 22, 2009 at 7:51 PM, ankur jain<[email protected]> wrote: >> > hi joel...do u hav any suggestion regarding this?? >> > >> > On Tue, Jul 21, 2009 at 10:57 PM, ankuur <[email protected]> wrote: >> >> >> >> hi >> >> >> >> We are using the gwt 2.0 code from gwt trunk.And we hav seen a drastic >> >> improvement in the page loading especially in case of IE(6 and >> >> 7).Actully breaking the compiled code into the multiple <script> tag >> >> did the trick. >> >> But now we are facing the browser memory problem.Actully our total >> >> compiled script size(in OBF mode) >> >> is more than 3 MB.As we use the application the browser memory keeps >> >> on increasing and sometimes it even reached to the 700MB. >> >> >> >> We tried to profile the application using the javascript tool(like >> >> firebug) but of no use because the only provides the performance >> >> metrics and not any memory leaks. >> >> >> >> Now we are trying to profile the gwt in the OOPHM mode while >> >> debugging.Its helpful and we are able to find some of the problems in >> >> our code.But actully during debugging time most of the refrences are >> >> held by gwt code(mainly by JavaDispatchImpl class and by the static >> >> variable in RootPanel i.e. widgetstoDetach) and also all the asynccall >> >> backs are held by RequestBuilder. >> >> >> >> We are assuming that these refrences wont be hold in the compiled >> >> mode,because all the classes we see are the debugger classes.But its >> >> making that profiling very tedious as we need to search what refrences >> >> are held by the gwt and where our classes are keeping refrence. >> >> >> >> I dont know we are going through correct approch fpr profiling or is >> >> there any other way so that we can check all the memory leaks and >> >> reduce the memory footprint of our application in the browser. >> >> >> >> Any help in this heartly welcomed.And also if we can reduce the objects >> >> (especially all the RPCs callbacks) then actully we can reduce the >> >> meomory used during debugging and it might help in mking it faster. >> >> >> >> regards >> >> ankur >> > >> > >> > > >> > >> >> >> >> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
