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<xs4an...@gmail.com> wrote: > hi joel...do u hav any suggestion regarding this?? > > On Tue, Jul 21, 2009 at 10:57 PM, ankuur <xs4an...@gmail.com> 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 Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
