hi Actully we have built the code from the gwt trunk.....so the breaking of code is not done manually....it is one of the feature of gwt 2.0.
Its true that only our application is running on the browser and the memory has reached upto 700MB.....and out codebase really huge with lots of RPCs,DTOs and many custom components.I am not sure about the exact size of codebase...will update u soon with it. We have found some leaks in our application.One of the greatest leak that we found in the glasspanel.So for now we are using just a static glasspanel(From gwt incubator ) and only adding and removing from the rootpanel.....so for now the problem has been partially fixed at its leaking only on window close.Still we need to figure out why glasspanel is leaking.....may be we could found a leak pattern. Another possible leak are may be that gwt always creates a new XMLHTTPRequest object,I tried with a sample appliction both on firefox and ie....i was just sending a byte array of size 10000 from client to server and vice versa.In IE memory kept on increasing while in firefox it was constant.In that sample i tried to reuse the XHR object,the memory seems to be stable in IE after that.But reusing of XHR seems to breaking somewhere as that logic cripped when tried with our main application(may be because in sample there was onl one RPC so it would hav worked). There is actully some caching problem with ie......setting no-cache header is also not helping out. We didnt tried out runasync as such but we plan to do it.....not now some time later. Actully there is some problem with the logic how the gwt guys are clearing the objects in the threadlocal of the JavaDispatchImpl and in the objects collection of the ObjectTable.java class. I saw the code they have the logic to clear the objects when they get a free message from the browser they free up the object from the collection of the Object table class.We saw the free request is comming for many objects but it never comback for the callback objects so they are always in the browser memory.This can be easily seen using jprofiler to profile the starter application while debugging. May be this problem is only at debug time....I am thinking to raise it.But OOPHM is not yet released, so i am not sure if i can raise that issue. regards ankur On Jul 30, 10:10 pm, Sumit Chandel <[email protected]> wrote: > 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- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
