Announcement Announcement Module
Collapse
No announcement yet.
Performance problems with Eclipse/STS + Roo Project Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Also I found out that in my case most of the build time (and the afterwards occuring "validation" phase) is spend with getting the xsds for the spring (and spring security/ integration) xml files. It seems as if STS requests the xsds from the web instead of using the ones inside the according jar files.
    Alex, the re-validation of Spring XML files is not triggered by changes to entities or aspects. So this is not the root cause. Additionally Wolfram is experiencing the slow builds on Eclipse JEE + AJDT; so no Spring validation of any sort.

    Also how did you verify that STS "requests the xsds from the web ..."? Do you have some stacktraces or other evidence? In my tests, STS always uses the known XSDs from the Eclipse XML catalog.

    Christian

    Comment


    • #17
      Sorry to add onto this thread. On my Mac with the latest STS, it is extremely slow.

      I definitely tell the students, when demoing Roo to them in class, that it is my fault and my settings on my machine running STS.

      I don't change any setting because I actually prefer IntelliJ and only go into STS for class, and now my one personal project that I am using Roo for. But for me I can deal with the slowness when running the app, because I know once I "push-in" I am going to go back to IntelliJ.

      Mark

      Comment


      • #18
        Sorry to add onto this thread. On my Mac with the latest STS, it is extremely slow.
        What version of STS for Mac are you using? Any chance you are using one of the Cocoa packages? If so, please try the Carbon version as the Eclipse Cocoa port is known to have performance issues.

        If not what concrete issues do you see? What is slow?

        Christian

        Comment


        • #19
          Hi Christian,

          Originally posted by Christian Dupuis View Post
          Alex, the re-validation of Spring XML files is not triggered by changes to entities or aspects. So this is not the root cause. Additionally Wolfram is experiencing the slow builds on Eclipse JEE + AJDT; so no Spring validation of any sort.

          Also how did you verify that STS "requests the xsds from the web ..."? Do you have some stacktraces or other evidence? In my tests, STS always uses the known XSDs from the Eclipse XML catalog.
          I tested this by simply removing the network plug from my laptop. STS/ Eclipse then complains that "loading of the required resources took longer than 60seconds...". I will try to reproduce that case and send you the eclipse error log by mail if that's ok.

          I also come to this conclusion as changing e.g. the database config xml in a project (osgi bundle) other projects depend on (via maven) takes an eternity - even if there is only a blank line added.
          Again I could send you a sample workspace (tested on winXP SP3+sun jdk6u18) but actually I'd like to test it against a clean STS2.3.1 installation to exclude any interference of my other eclipse plugins.

          @Ben
          If you turn off all validations for spring xml files does this only effect warning and error markers? Meaning
          a) is context assistant still available
          b) are aspectj markers still showing up

          Alex

          Comment


          • #20
            I am actually using the one that comes with the Mac installer for the Core Spring class. The latest Spring 3.0 class. I taught it two weeks ago and used the installer that is now on the pen drives.

            Mark

            Comment


            • #21
              I am actually using the one that comes with the Mac installer for the Core Spring class. The latest Spring 3.0 class. I taught it two weeks ago and used the installer that is now on the pen drives.
              Yeah, Core Spring 3.0 ships the Cocoa build which is known to have performance issues. Please try with a Carbon version.

              Christian

              Comment


              • #22
                Well, the Carbon version seems very slow too without modifying anything

                Going to my apps page in STS

                Start time
                INFO: Initializing Spring FrameworkServlet 'bandapp'
                2010-03-10 13:56:37

                I guess deploy completion
                2010-03-10 13:58:52,490 [tomcat-http--6] INFO org.springframework.web.servlet.DispatcherServlet - FrameworkServlet 'bandapp': initialization completed in 135026 ms

                Now I changed the xms to 256M and kept the permgen at 256M and here are the faster results

                INFO: Initializing Spring FrameworkServlet 'bandapp'
                2010-03-10 14:35:53

                2010-03-10 14:36:28,705 [tomcat-http--2] INFO org.springframework.web.servlet.DispatcherServlet - FrameworkServlet 'bandapp': initialization completed in 34909 ms

                So from 2 minutes 15 seconds down to 35 seconds.

                Just for anyone else who might have a slow STS running on Mac.

                Mark

                Comment


                • #23
                  Originally posted by aheusingfeld View Post
                  Also I found out that in my case most of the build time (and the afterwards occuring "validation" phase) is spend with getting the xsds for the spring (and spring security/ integration) xml files. It seems as if STS requests the xsds from the web instead of using the ones inside the according jar files.

                  @Wolfram Can you assure this isn't the case in your scenario?
                  Yes, that's not the case, never saw that action taking place in any log I checked. "Deleting and creating markers..." is where I am (or was? see below) stuck. A sidenote: "perform eclipse" does not add maven2Nature to my project, which is fine with me. I simply call that again when I add another dependency.

                  ---

                  Right now, my problems come down to the recreation of all aspectj markers on every change. Normally I run into this by 1) changing something 2) saving the file 3) immediately see a typo or missing import, thus changing and saving again. This is when the nice window is popping up telling me that everyone including myself will have to wait for the markers.

                  However, I just finished installing STS 2.3.1 (carbon) and opened up a source file, tried the three steps above and no window is showing + the file is saved instantly. The markers are still recreated but the time needed dropped from 6s to 0.4s, which is nice. Let's hope it stays this way.

                  @Christian:
                  Looking forward to your talk in Munich ("Extreme Productivity with Spring Roo" ... and STS ?!). I'll closely keep an eye on the STS performance on stage (if you use it at all).

                  Comment

                  Working...
                  X