Grails development is really slow
Locked
123456
123456
Re: Grails development is really slow
 
|
Since you have only 2GB RAM, it might be worth adjusting GRAILS_OPTS env. variable to lower values. In Grails 2.0, the default is: GRAILS_OPTS=-server -Xmx768M -Xms768M -XX:PermSize=256m -XX:MaxPermSize=256m -Dfile.encoding=UTF-8 You could try: GRAILS_OPTS=-server -Xmx600M -Xms600M -XX:PermSize=200m -XX:MaxPermSize=200m -Dfile.encoding=UTF-8 (In windows, set GRAILS_OPTS in the same place (My computer->properties->advanced->environment variables) as you would modify the PATH setting) -- Some other points to verify: On windows, you might want to add the HOME_DIR/.grails to the exclusions of your Anti-virus software. The same applies to your Grails's project directory. Many anti-virus packages automaticly scan all new files and changed files and that causes a lot of overhead (some anti-virus packages even unzip jar files and scan the included files on the fly). If it's still slow, try removing HOME_DIR/.grails/.slcache directory (it's the cache directory of the Spring Loaded Java agent that Grails 2.0 uses for reloading). (I've experienced that problem once before in Grails 2.0 pre-release versions; it made everything extremely slow and it got fixed by cleaning the .grails/.slcache dir). Lari 05.01.2012 13:38, raffaele181188 wrote: Without STS everything seems a little faster. But still I want to use an IDE. Moreover, I have monitored both RAM and CPU usage and both are around 70% at most. It seems that grails it's just slow! It's very strange... Also, trying to request the page via browser takes too long.. Several second after I have just saved a file. |
Re: Grails development is really slow
|
|
A Stackoverflow answer related to Eclipse performance and Windows anti-virus software settings: http://stackoverflow.com/a/2434369/166062 Lari 05.01.2012 15:12, Lari Hotari wrote:
|
|
In reply to this post by virtualeyes
Hi virtualeyes,
Em 04-01-2012 19:51, virtualeyes escreveu: > ... The reality is that Grails > is in fact absurdly fast to restart, faster than or as fast as, cough-cough, > Rails. I have no idea where you did take your estimates from. In my PC, Grails takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about 16s and Rails itself (on CRuby) takes a single second. I guess you were talking about using the interactive console for booting the Grails app. In that case, for an empty app, it takes about 2 seconds here, which is still a bit slower than vanilla Rails, but certainly much faster than JRuby on Rails. But anyway, I'm not really much concerned about the time required to boot the application as long as I only have to do it once. My main gripe with Grails 1.3.7 is that it would reboot after each little change to my domain classes and other source files, and that took a huge time. Now, with Grails 2, even without the interactive console, the user experience is much better as I don't need to often reboot the application. The interactive console just makes Grails even more responsive. But in the expense of subtle bugs that will show up when using the interactive console that wouldn't be present otherwise... The main disadvantage of a slow bootup time (in any framework/environment) is that it makes running your integration tests slower. While using Rspec for writing tests for Rails, one can use Spork that will take a similar approach to the one taken from Grails interactive console, that will make tests run much faster. So, that article that you mentioned is certainly out-of-date and I need to rewrite it when I find some time. I'll write a new one and add a deprecation note on that one when I'm done for keeping the old comments. My main gripe with Grails currently is that I find it very hard to debug and find what is causing troubles in my application setup. I often have to create a fresh Grails app and gradually copy my files to there until I find the source of the problem. The Grails error messages don't give me a single clue about the problem most of the times. That is not to say that I have no more issues with Grails. I don't like it in many ways, but I find the over-complex black magic behind Grails the one that takes be most of the time when I'm trying to identify some issues. Also, I find that the Grails community has poor support when compared with the Rails and Ruby one. I have lots of unanswered messages in this list where I point to buggy scenarios or plugins. For, example, I've filled two bugs in the Rails issues system last year, and both were fixed and commited in less than an hour: https://github.com/rails/rails/issues/4054 https://github.com/rails/rails/issues/4067 In the other side, here are some bugs (or feature requests) I've reported to the Grails JIRA: http://jira.grails.org/browse/GRAILS-8568 http://jira.grails.org/browse/GRAILS-8567 http://jira.grails.org/browse/GPCONSOLE-3 http://jira.grails.org/browse/GRAILS-8539 (I'm the only one participating on this one, for example) http://jira.grails.org/browse/GRAILS-8485 http://jira.grails.org/browse/GRAILS-7792 (feature request) http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although I think it could be fixed...) https://github.com/SpringSource/grails-data-mapping/issues/18 Unanswered messages in this list: http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html this wasn't answered. It was just told me to not report bugs in the dev mailing list, but I didn't get any reply in the user's list too http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html just a minor part of the message was answered http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html http://www.digipedia.pl/usenet/thread/14352/30474/ http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html (I've got only a suggestion to use another testing framework, but didn't get a real answer to what I was asking for) http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html Also, besides free time, I still need some more time experimenting with Grails 2 before I can write the new article on the subject... Best, Rodrigo. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
In reply to this post by raffaele181188
Em 05-01-2012 09:38, raffaele181188 escreveu:
> Without STS everything seems a little faster. But still I want to use > an IDE. Moreover, I have monitored both RAM and CPU usage and both are > around 70% at most. It seems that grails it's just slow! It's very > strange... Also, trying to request the page via browser takes too > long.. Several second after I have just saved a file. > Do you experience this "slow" development cycle? Is it normal or is it > just on my machine? > No, Raffaele, it shouldn't be that slow. You should really consider the advice on buying 8GB of RAM. It will save you lot of time even if you decide for not using Grails at all. And time is money (usually). --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Grails development is really slow
Administrator
|
In reply to this post by rosenfeld
On Thu, Jan 5, 2012 at 2:17 PM, Rodrigo Rosenfeld Rosas
<[hidden email]> wrote: > Hi virtualeyes, > > Em 04-01-2012 19:51, virtualeyes escreveu: >> >> ... The reality is that Grails >> >> is in fact absurdly fast to restart, faster than or as fast as, >> cough-cough, >> Rails. > > > I have no idea where you did take your estimates from. In my PC, Grails > takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about > 16s and Rails itself (on CRuby) takes a single second. I guess you were > talking about using the interactive console for booting the Grails app. In > that case, for an empty app, it takes about 2 seconds here, which is still a > bit slower than vanilla Rails, but certainly much faster than JRuby on > Rails. > > But anyway, I'm not really much concerned about the time required to boot > the application as long as I only have to do it once. My main gripe with > Grails 1.3.7 is that it would reboot after each little change to my domain > classes and other source files, and that took a huge time. > > Now, with Grails 2, even without the interactive console, the user > experience is much better as I don't need to often reboot the application. > The interactive console just makes Grails even more responsive. But in the > expense of subtle bugs that will show up when using the interactive console > that wouldn't be present otherwise... > > The main disadvantage of a slow bootup time (in any framework/environment) > is that it makes running your integration tests slower. While using Rspec > for writing tests for Rails, one can use Spork that will take a similar > approach to the one taken from Grails interactive console, that will make > tests run much faster. > > So, that article that you mentioned is certainly out-of-date and I need to > rewrite it when I find some time. I'll write a new one and add a deprecation > note on that one when I'm done for keeping the old comments. > > My main gripe with Grails currently is that I find it very hard to debug and > find what is causing troubles in my application setup. I often have to > create a fresh Grails app and gradually copy my files to there until I find > the source of the problem. > > The Grails error messages don't give me a single clue about the problem most > of the times. That is not to say that I have no more issues with Grails. I > don't like it in many ways, but I find the over-complex black magic behind > Grails the one that takes be most of the time when I'm trying to identify > some issues. > > Also, I find that the Grails community has poor support when compared with > the Rails and Ruby one. I have lots of unanswered messages in this list > where I point to buggy scenarios or plugins. Many of your issues (understandably) come from the perspective of a Rails developer. The fact that you have are upset that you have unanswered questions on integrating a Ruby testing framework into Grails does surprise me however. You would also get your issues fixed quicker if you provided reproducible steps in the issues you raised. Most of your reports are incomplete / don't have examples attached and amount to "something doesn't work" instead of providing accurate steps to reproduce the problem. They are reactionary and tend to be unhelpful. You'll notice that users who report issues with actual examples (attached example applications or test cases) get their issues fixed a lot quicker. You also frequently use the mailing list to report issues instead of JIRA, if you believe you have identified a bug then raise a JIRA. Emailing the developer list doesn't help either. Cheers > > For, example, I've filled two bugs in the Rails issues system last year, and > both were fixed and commited in less than an hour: > > https://github.com/rails/rails/issues/4054 > https://github.com/rails/rails/issues/4067 > > In the other side, here are some bugs (or feature requests) I've reported to > the Grails JIRA: > > http://jira.grails.org/browse/GRAILS-8568 > http://jira.grails.org/browse/GRAILS-8567 > http://jira.grails.org/browse/GPCONSOLE-3 > http://jira.grails.org/browse/GRAILS-8539 (I'm the only one participating on > this one, for example) > http://jira.grails.org/browse/GRAILS-8485 > http://jira.grails.org/browse/GRAILS-7792 (feature request) > http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although I > think it could be fixed...) > https://github.com/SpringSource/grails-data-mapping/issues/18 > > Unanswered messages in this list: > > http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html > http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html > this wasn't answered. It was just told me to not report bugs in the dev > mailing list, but I didn't get any reply in the user's list too > http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html > just a minor part of the message was answered > http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html > http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html > http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html > http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html > http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html > http://www.digipedia.pl/usenet/thread/14352/30474/ > http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html > (I've got only a suggestion to use another testing framework, but didn't get > a real answer to what I was asking for) > http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html > > > Also, besides free time, I still need some more time experimenting with > Grails 2 before I can write the new article on the subject... > > Best, > > Rodrigo. > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Graeme Rocher Grails Project Lead SpringSource - A Division of VMware http://www.springsource.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Grails development is really slow
|
In reply to this post by rosenfeld
Sorry for cherry-picking into a long email and a long thread, but your
Rails/Grails bug comparison is very weak. You reported two simple Rails bugs that were each fixed with a single line of code, and are comparing these to Grails issues that are a significantly more involved. Burt On Thursday, January 05, 2012 11:17:45 AM Rodrigo Rosenfeld Rosas wrote: > Hi virtualeyes, > > Em 04-01-2012 19:51, virtualeyes escreveu: > > ... The reality is that Grails > > is in fact absurdly fast to restart, faster than or as fast as, cough- cough, > > Rails. > > I have no idea where you did take your estimates from. In my PC, Grails > takes from 36 to 40s to boot an empty app, while JRuby on Rails takes > about 16s and Rails itself (on CRuby) takes a single second. I guess you > were talking about using the interactive console for booting the Grails > app. In that case, for an empty app, it takes about 2 seconds here, > which is still a bit slower than vanilla Rails, but certainly much > faster than JRuby on Rails. > > But anyway, I'm not really much concerned about the time required to > boot the application as long as I only have to do it once. My main gripe > with Grails 1.3.7 is that it would reboot after each little change to my > domain classes and other source files, and that took a huge time. > > Now, with Grails 2, even without the interactive console, the user > experience is much better as I don't need to often reboot the > application. The interactive console just makes Grails even more > responsive. But in the expense of subtle bugs that will show up when > using the interactive console that wouldn't be present otherwise... > > The main disadvantage of a slow bootup time (in any > framework/environment) is that it makes running your integration tests > slower. While using Rspec for writing tests for Rails, one can use Spork > that will take a similar approach to the one taken from Grails > interactive console, that will make tests run much faster. > > So, that article that you mentioned is certainly out-of-date and I need > to rewrite it when I find some time. I'll write a new one and add a > deprecation note on that one when I'm done for keeping the old comments. > > My main gripe with Grails currently is that I find it very hard to debug > and find what is causing troubles in my application setup. I often have > to create a fresh Grails app and gradually copy my files to there until > I find the source of the problem. > > The Grails error messages don't give me a single clue about the problem > most of the times. That is not to say that I have no more issues with > Grails. I don't like it in many ways, but I find the over-complex black > magic behind Grails the one that takes be most of the time when I'm > trying to identify some issues. > > Also, I find that the Grails community has poor support when compared > with the Rails and Ruby one. I have lots of unanswered messages in this > list where I point to buggy scenarios or plugins. > > For, example, I've filled two bugs in the Rails issues system last year, > and both were fixed and commited in less than an hour: > > https://github.com/rails/rails/issues/4054 > https://github.com/rails/rails/issues/4067 > > In the other side, here are some bugs (or feature requests) I've > reported to the Grails JIRA: > > http://jira.grails.org/browse/GRAILS-8568 > http://jira.grails.org/browse/GRAILS-8567 > http://jira.grails.org/browse/GPCONSOLE-3 > http://jira.grails.org/browse/GRAILS-8539 (I'm the only one > participating on this one, for example) > http://jira.grails.org/browse/GRAILS-8485 > http://jira.grails.org/browse/GRAILS-7792 (feature request) > http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although > I think it could be fixed...) > https://github.com/SpringSource/grails-data-mapping/issues/18 > > Unanswered messages in this list: > > http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find- > http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing- well-together-td4222229.html > this wasn't answered. It was just told me to not report bugs in the dev > mailing list, but I didn't get any reply in the user's list too > http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not- talking-about-replication-td4210794.html > just a minor part of the message was answered > http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default- mapping-options-to-all-columns-of-some-GORM-class-td4210934.html > http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping- version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html > http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses- deprecated-ConfigurationHolder-td4208027.html > http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception- while-trying-to-autocomplete-a-Map-td4205530.html > http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7- and-have-no-clue-all-requests-yields-to-404-status-td4178489.html > http://www.digipedia.pl/usenet/thread/14352/30474/ > http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled- domain-classes-td3868599.html > (I've got only a suggestion to use another testing framework, but didn't > get a real answer to what I was asking for) > http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html > > > Also, besides free time, I still need some more time experimenting with > Grails 2 before I can write the new article on the subject... > > Best, > > Rodrigo. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Grails development is really slow
|
quick question... who gives a shit about rails or ruby, can we focus
on fixing the problem. Not replacing every stinking technology the OP is using. lame... On Thu, Jan 5, 2012 at 6:51 AM, Burt Beckwith <[hidden email]> wrote: > Sorry for cherry-picking into a long email and a long thread, but your > Rails/Grails bug comparison is very weak. You reported two simple Rails bugs > that were each fixed with a single line of code, and are comparing these to > Grails issues that are a significantly more involved. > > Burt > > On Thursday, January 05, 2012 11:17:45 AM Rodrigo Rosenfeld Rosas wrote: >> Hi virtualeyes, >> >> Em 04-01-2012 19:51, virtualeyes escreveu: >> > ... The reality is that Grails >> > is in fact absurdly fast to restart, faster than or as fast as, cough- > cough, >> > Rails. >> >> I have no idea where you did take your estimates from. In my PC, Grails >> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes >> about 16s and Rails itself (on CRuby) takes a single second. I guess you >> were talking about using the interactive console for booting the Grails >> app. In that case, for an empty app, it takes about 2 seconds here, >> which is still a bit slower than vanilla Rails, but certainly much >> faster than JRuby on Rails. >> >> But anyway, I'm not really much concerned about the time required to >> boot the application as long as I only have to do it once. My main gripe >> with Grails 1.3.7 is that it would reboot after each little change to my >> domain classes and other source files, and that took a huge time. >> >> Now, with Grails 2, even without the interactive console, the user >> experience is much better as I don't need to often reboot the >> application. The interactive console just makes Grails even more >> responsive. But in the expense of subtle bugs that will show up when >> using the interactive console that wouldn't be present otherwise... >> >> The main disadvantage of a slow bootup time (in any >> framework/environment) is that it makes running your integration tests >> slower. While using Rspec for writing tests for Rails, one can use Spork >> that will take a similar approach to the one taken from Grails >> interactive console, that will make tests run much faster. >> >> So, that article that you mentioned is certainly out-of-date and I need >> to rewrite it when I find some time. I'll write a new one and add a >> deprecation note on that one when I'm done for keeping the old comments. >> >> My main gripe with Grails currently is that I find it very hard to debug >> and find what is causing troubles in my application setup. I often have >> to create a fresh Grails app and gradually copy my files to there until >> I find the source of the problem. >> >> The Grails error messages don't give me a single clue about the problem >> most of the times. That is not to say that I have no more issues with >> Grails. I don't like it in many ways, but I find the over-complex black >> magic behind Grails the one that takes be most of the time when I'm >> trying to identify some issues. >> >> Also, I find that the Grails community has poor support when compared >> with the Rails and Ruby one. I have lots of unanswered messages in this >> list where I point to buggy scenarios or plugins. >> >> For, example, I've filled two bugs in the Rails issues system last year, >> and both were fixed and commited in less than an hour: >> >> https://github.com/rails/rails/issues/4054 >> https://github.com/rails/rails/issues/4067 >> >> In the other side, here are some bugs (or feature requests) I've >> reported to the Grails JIRA: >> >> http://jira.grails.org/browse/GRAILS-8568 >> http://jira.grails.org/browse/GRAILS-8567 >> http://jira.grails.org/browse/GPCONSOLE-3 >> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one >> participating on this one, for example) >> http://jira.grails.org/browse/GRAILS-8485 >> http://jira.grails.org/browse/GRAILS-7792 (feature request) >> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although >> I think it could be fixed...) >> https://github.com/SpringSource/grails-data-mapping/issues/18 >> >> Unanswered messages in this list: >> >> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find- > with-closure-td4222761.html >> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing- > well-together-td4222229.html >> this wasn't answered. It was just told me to not report bugs in the dev >> mailing list, but I didn't get any reply in the user's list too >> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not- > talking-about-replication-td4210794.html >> just a minor part of the message was answered >> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default- > mapping-options-to-all-columns-of-some-GORM-class-td4210934.html >> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping- > version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html >> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses- > deprecated-ConfigurationHolder-td4208027.html >> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception- > while-trying-to-autocomplete-a-Map-td4205530.html >> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7- > and-have-no-clue-all-requests-yields-to-404-status-td4178489.html >> http://www.digipedia.pl/usenet/thread/14352/30474/ >> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled- > domain-classes-td3868599.html >> (I've got only a suggestion to use another testing framework, but didn't >> get a real answer to what I was asking for) >> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html >> >> >> Also, besides free time, I still need some more time experimenting with >> Grails 2 before I can write the new article on the subject... >> >> Best, >> >> Rodrigo. > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Grails development is really slow
|
|
quick question... who gives a crap about rails or ruby, can we focus
on fixing the problem. Not replacing every stinking technology the OP is using. lame... On Thu, Jan 5, 2012 at 7:06 AM, Jason Davis <[hidden email]> wrote: > quick question... who gives a shit about rails or ruby, can we focus > on fixing the problem. Not replacing every stinking technology the OP > is using. lame... > > On Thu, Jan 5, 2012 at 6:51 AM, Burt Beckwith <[hidden email]> wrote: >> Sorry for cherry-picking into a long email and a long thread, but your >> Rails/Grails bug comparison is very weak. You reported two simple Rails bugs >> that were each fixed with a single line of code, and are comparing these to >> Grails issues that are a significantly more involved. >> >> Burt >> >> On Thursday, January 05, 2012 11:17:45 AM Rodrigo Rosenfeld Rosas wrote: >>> Hi virtualeyes, >>> >>> Em 04-01-2012 19:51, virtualeyes escreveu: >>> > ... The reality is that Grails >>> > is in fact absurdly fast to restart, faster than or as fast as, cough- >> cough, >>> > Rails. >>> >>> I have no idea where you did take your estimates from. In my PC, Grails >>> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes >>> about 16s and Rails itself (on CRuby) takes a single second. I guess you >>> were talking about using the interactive console for booting the Grails >>> app. In that case, for an empty app, it takes about 2 seconds here, >>> which is still a bit slower than vanilla Rails, but certainly much >>> faster than JRuby on Rails. >>> >>> But anyway, I'm not really much concerned about the time required to >>> boot the application as long as I only have to do it once. My main gripe >>> with Grails 1.3.7 is that it would reboot after each little change to my >>> domain classes and other source files, and that took a huge time. >>> >>> Now, with Grails 2, even without the interactive console, the user >>> experience is much better as I don't need to often reboot the >>> application. The interactive console just makes Grails even more >>> responsive. But in the expense of subtle bugs that will show up when >>> using the interactive console that wouldn't be present otherwise... >>> >>> The main disadvantage of a slow bootup time (in any >>> framework/environment) is that it makes running your integration tests >>> slower. While using Rspec for writing tests for Rails, one can use Spork >>> that will take a similar approach to the one taken from Grails >>> interactive console, that will make tests run much faster. >>> >>> So, that article that you mentioned is certainly out-of-date and I need >>> to rewrite it when I find some time. I'll write a new one and add a >>> deprecation note on that one when I'm done for keeping the old comments. >>> >>> My main gripe with Grails currently is that I find it very hard to debug >>> and find what is causing troubles in my application setup. I often have >>> to create a fresh Grails app and gradually copy my files to there until >>> I find the source of the problem. >>> >>> The Grails error messages don't give me a single clue about the problem >>> most of the times. That is not to say that I have no more issues with >>> Grails. I don't like it in many ways, but I find the over-complex black >>> magic behind Grails the one that takes be most of the time when I'm >>> trying to identify some issues. >>> >>> Also, I find that the Grails community has poor support when compared >>> with the Rails and Ruby one. I have lots of unanswered messages in this >>> list where I point to buggy scenarios or plugins. >>> >>> For, example, I've filled two bugs in the Rails issues system last year, >>> and both were fixed and commited in less than an hour: >>> >>> https://github.com/rails/rails/issues/4054 >>> https://github.com/rails/rails/issues/4067 >>> >>> In the other side, here are some bugs (or feature requests) I've >>> reported to the Grails JIRA: >>> >>> http://jira.grails.org/browse/GRAILS-8568 >>> http://jira.grails.org/browse/GRAILS-8567 >>> http://jira.grails.org/browse/GPCONSOLE-3 >>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one >>> participating on this one, for example) >>> http://jira.grails.org/browse/GRAILS-8485 >>> http://jira.grails.org/browse/GRAILS-7792 (feature request) >>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although >>> I think it could be fixed...) >>> https://github.com/SpringSource/grails-data-mapping/issues/18 >>> >>> Unanswered messages in this list: >>> >>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find- >> with-closure-td4222761.html >>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing- >> well-together-td4222229.html >>> this wasn't answered. It was just told me to not report bugs in the dev >>> mailing list, but I didn't get any reply in the user's list too >>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not- >> talking-about-replication-td4210794.html >>> just a minor part of the message was answered >>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default- >> mapping-options-to-all-columns-of-some-GORM-class-td4210934.html >>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping- >> version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html >>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses- >> deprecated-ConfigurationHolder-td4208027.html >>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception- >> while-trying-to-autocomplete-a-Map-td4205530.html >>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7- >> and-have-no-clue-all-requests-yields-to-404-status-td4178489.html >>> http://www.digipedia.pl/usenet/thread/14352/30474/ >>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled- >> domain-classes-td3868599.html >>> (I've got only a suggestion to use another testing framework, but didn't >>> get a real answer to what I was asking for) >>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html >>> >>> >>> Also, besides free time, I still need some more time experimenting with >>> Grails 2 before I can write the new article on the subject... >>> >>> Best, >>> >>> Rodrigo. >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Grails development is really slow
|
+1 for the anti virus checking. I won't be able to test it untile next Monday, but hopefully this will solve the problem
Please undertand that even if RAM is very cheap I cannot buy and install it myself without explict admins consensus :(
Also I remark that my monitors never show a RAM usage over 70%, so we are pretty far away from swap land I have to ask one more question. I have some background in PHP and I must say that the development lifecycle is very smooth.
Now the new company I work for is mostly Java based, and I must say that developing (and deploying!) feels really slow compared to PHP If you have any experience in other dynamic languages frameworks (PHP, Ruby + Rails, Python, Scala), how do you compare those to
Grails development? I'm talking about the "development speed", where the reference is the PHP cycle: 1. Edit file 2. Refresh the browser 3. (at deploy time) Copy files
Raffaele 2012/1/5 Jason Davis [via Grails] <[hidden email]> quick question... who gives a crap about rails or ruby, can we focus |
|
It is really hard to compare. But for JAVA people, Grails should the top choice. On Thu, Jan 5, 2012 at 6:33 AM, raffaele181188 <[hidden email]> wrote: +1 for the anti virus checking. I won't be able to test it untile next Monday, but hopefully this will solve the problem |
Re: Grails development is really slow
|
|
But Java itself is not such a smooth experience. My primary objective is find a language that feels like PHP, withouth being PHP :P
and with a good framework for webapps. Grails seemed perfect, but I expected a smoother experience..
2012/1/5 xmly [via Grails] <[hidden email]>
|
Re: Grails development is really slow
|
php != grails. You are going about it the wrong way. People picking up different languages and frameworks expecting it to work like something else. Hmmm, maybe I'll pick up Objective C expecting it feel like basic.
On Thu, Jan 5, 2012 at 9:36 AM, raffaele181188 <[hidden email]> wrote: But Java itself is not such a smooth experience. My primary objective is find a language that feels like PHP, withouth being PHP :P The Journey Is The Reward. |
|
|
In reply to this post by Graeme Rocher-4
Em 05-01-2012 11:43, Graeme Rocher escreveu:
> On Thu, Jan 5, 2012 at 2:17 PM, Rodrigo Rosenfeld Rosas > <[hidden email]> wrote: >> Hi virtualeyes, >> >> Em 04-01-2012 19:51, virtualeyes escreveu: >>> ... The reality is that Grails >>> >>> is in fact absurdly fast to restart, faster than or as fast as, >>> cough-cough, >>> Rails. >> >> I have no idea where you did take your estimates from. In my PC, Grails >> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about >> 16s and Rails itself (on CRuby) takes a single second. I guess you were >> talking about using the interactive console for booting the Grails app. In >> that case, for an empty app, it takes about 2 seconds here, which is still a >> bit slower than vanilla Rails, but certainly much faster than JRuby on >> Rails. >> >> But anyway, I'm not really much concerned about the time required to boot >> the application as long as I only have to do it once. My main gripe with >> Grails 1.3.7 is that it would reboot after each little change to my domain >> classes and other source files, and that took a huge time. >> >> Now, with Grails 2, even without the interactive console, the user >> experience is much better as I don't need to often reboot the application. >> The interactive console just makes Grails even more responsive. But in the >> expense of subtle bugs that will show up when using the interactive console >> that wouldn't be present otherwise... >> >> The main disadvantage of a slow bootup time (in any framework/environment) >> is that it makes running your integration tests slower. While using Rspec >> for writing tests for Rails, one can use Spork that will take a similar >> approach to the one taken from Grails interactive console, that will make >> tests run much faster. >> >> So, that article that you mentioned is certainly out-of-date and I need to >> rewrite it when I find some time. I'll write a new one and add a deprecation >> note on that one when I'm done for keeping the old comments. >> >> My main gripe with Grails currently is that I find it very hard to debug and >> find what is causing troubles in my application setup. I often have to >> create a fresh Grails app and gradually copy my files to there until I find >> the source of the problem. >> >> The Grails error messages don't give me a single clue about the problem most >> of the times. That is not to say that I have no more issues with Grails. I >> don't like it in many ways, but I find the over-complex black magic behind >> Grails the one that takes be most of the time when I'm trying to identify >> some issues. >> >> Also, I find that the Grails community has poor support when compared with >> the Rails and Ruby one. I have lots of unanswered messages in this list >> where I point to buggy scenarios or plugins. > > Many of your issues (understandably) come from the perspective of a > Rails developer. Sorry, Graeme, could you point me out what issues you think is associated to my perspective as a Rails developer? I can only remember the one about integrating Capybara to Grails. But as you said "many of your issues", I'd be curious to understand what are the other issues associated to my Rails background... > The fact that you are upset that you have > unanswered questions on integrating a Ruby testing framework into > Grails does surprise me however. Integrating JRuby and Grails wasn't exactly the part I was looking for help. At that point I was already able to boot a Grails app from Capybara running on JRuby and could also write HTTP-only based specs and it would work. But than I couldn't see much advantage on this approach when compared with Selenium, for instance. The advantage of running the specs with access to the application context is that I would be able to change the state of the database before each test and use the GORM classes, for example, for writing my expectations. So, I just asked about Grails internals and how it does inject the GORM methods inside the Grails domain classes so that I could try to do that from the JRuby process. I guess JRuby and Groovy still don't inter-operate very well, sharing methodMissing, for example. But if I could use the other methods aside from the dynamic finders from Java (and JRuby as a consequence), I would be able to create the instances I'd like to in my specs as well as using methods like list and count that could be injected in the class itself through bytecode so that a Java app could see them. I'm not complaining at me not accomplishing my goal, but at no one to have even tried to explain me how GORM internals work so that I could decide if my approach was feasible or not. I have also asked for some features in the Rails-core and ruby-core list that were rejected. But at least I had some feedback and some explanations why they were rejected. Even if I don't agree with them, the important bit here is that I always got answered. > You would also get your issues fixed quicker if you provided > reproducible steps in the issues you raised. Most of your reports are > incomplete / don't have examples attached and amount to "something > doesn't work" instead of providing accurate steps to reproduce the > problem. They are reactionary and tend to be unhelpful. You can see them as reactionary but they are actually the best description I could get. Believe me: I would certainly give you the precise source of the issues if I knew it beforehand. For example, I have no idea about the reloading issues due to the Vim swap files when I first reported the bug. I thought it might be related to static methods as it only happened in my tests while working on them. But I didn't have a single clue from Grails messages that would associate the problem with the Vim swap files. For some unknown reason, it came to my mind that maybe my swap files were affecting the Grails loader issue somehow and I tried disabled them as a desperate act of clueless trying to find the source of the reloading issue. I was actually pretty surprised that disabling the swap files actually solved my reloading issues. If I knew beforehand that the cause was the Vim swap files, you can bet that I would have reported it from the beginning. I had no clue about the problem and I was hoping for some feedback that could help me identifying the cause of the issue. I don't hide any details on purpose. When I don't give many details is because I don't have more clues about the problem or I don't know how to reproduce them in a new app. I would expect some guidance on what to do to try gather more information about the issue so that I can give you better feedback. You shouldn't expect me to identify the exact issue that is causing troubles to me. I would expect instead that you could help me to eliminate some sources and guide me on how to get more information about the subject. I'll certainly help as much as I can, but I need some help usually. As you can see from the stacktrace in my reports, they're also clueless while identifying the source of the bug. The same way it doesn't help you, it doesn't help me either. I would appreciate if you could help me to find the culprit in the next reports instead of just ignoring them. > You'll notice that users who report issues with actual examples > (attached example applications or test cases) get their issues fixed a > lot quicker. > > You also frequently use the mailing list to report issues instead of > JIRA, if you believe you have identified a bug then raise a JIRA. > Emailing the developer list doesn't help either. Sometimes I'm wrong. That is why I prefer to confirm the bug first in the mailing list before raising a JIRA. This week, for instance, I was getting trouble while testing an implementation of Server-Side Events that I was creating in my app. For some reason it seemed that the Grails application was waiting for one request to complete before starting to handle the newer one. My first reaction was "WTF: isn't Grails 2 multi-thread anymore?!". I've tried running it under production environment and even create a new fresh app and it wouldn't handle the 2 requests concurrently. I was about to fill a new bug when I decided to try another browser. So, I've identified that Chrome wasn't issuing a new request to that address until the old one have completed... You can be sure that I take a lot of time before creating a JIRA issue in your system because I value the time you spend on them. I don't just throw any issues in your JIRA system before spending a lot of time trying to identify what is the cause before. Please, don't get the wrong impression about me. With regards to JIRA vs mailing list, I don't really understand why does it matter so much. A while ago, someone got in touch with me by e-mail asking for supporting the newest Rails release in my rails-web-console gem. I didn't ask him to open a new issue in the Github issues page of the project. I just fixed it in the same day and replied to him that the just released new version supported the latest Rails. While I find this responsiveness very common in the Ruby land, I can't say the same about the Grails-related projects/plugins I've worked with. For example, there is a long time issue with the Grails console plugin that doesn't work well on Chrome due to a bug on its CSS: http://grails.org/plugin/console I didn't report the bug the first time I've seen since I thought someone else would do it. I've just kept using the old 0.2.2 release. But after an year since it was released, there is still no newer version, so I decided I would investigate the cause. So, I've opening the JIRA issue pointing out what was the problem and how to fix it some days ago. But there is still no fixed version for it... My feeling is that things happen too slow in the Grails land. Also, I don't understand why there is a centralized model around plugin releases. Git is interesting because it allows a decentralized model to work. In Ruby, the RubyGems project will allow anyone to publish new gems without asking for permission to anyone. The Bundler project is a Maven-like, but improved, project for dealing with dependencies in Ruby. And it allows one to specify the dependency pointing directly to the Git URL among other options. That is really interesting when you have forked some project and fixed the issue yourself allowing you to use your fixed version while the original one doesn't get fixed. I find it really frustrating that someone needs to ask for permission/access in the dev mailing list for publishing a new plugin. I'd rather prefer a decentralized system like Git or RubyGems for things like this... Also, talking about community culture, it is very hard to find any Ruby project those days that is not hosted on GitHub. That is part of the culture of the Ruby community. I find it really weird that the Ruby language itself is still hosted on Subversion with a Git official mirror... GitHub is a great place to fork and send pull requests, specially because most of the projects have a big test suite that will make you more confident that you didn't break anything after your changes by running the test suite, which is part of the project itself and not a separate project. It is usually very easy to setup the test environment. While looking at the Grails plugins page, I can't find a link to the project in GitHub for most of them, which I find kind of frustrating since it would require more effort to me for contributing to them or sending them pull requests... Working with Git is so easy to me that I won't contribute to any project that is not Git hosted because it will require me more time to generate the patch, send them to the issues system and keep them up to date... I'm not blaming anyone for their choice, but this is just a choice I've made myself of not contributing to non-git projects as they will require me more free time I'm not willing to spend... Sorry for the long message, but I've realized I've never expressed those opinions before and I think I shouldn't wait for my next article to express them. Also, I'd like to thank you for the feedback I've got today with regards to some of the issues mentioned in this thread. I'm not ignoring them and will reply to them as soon as I find some time, but I'm afraid I have lots of work still to do today. Maybe tomorrow I can try to open the remaining issues in JIRA or attach some reproducible project to some of them. Cheers, Rodrigo. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
In reply to this post by raffaele181188
I have used Grails for almost 2 years. Before I have done two project using PHP/ZendFramework.
My personal feeling is that Grails is easy to start, but hard to master it. Grails is actually a collection of several famous tools: Spring/Hibernate/...
If you really want to understand what happened under the hood, you have to know each of them very well. So if your learning sequence is like: Servelet/JSP/JDBC -> Struts/Spring/ORM ->Groovy/Grails, then you would feel Wow.... But reversed learning cycle would be quite painful...
Based on what you said, I would recommend Python/Django, though Python3 is a problem. On Thu, Jan 5, 2012 at 7:36 AM, raffaele181188 <[hidden email]> wrote: But Java itself is not such a smooth experience. My primary objective is find a language that feels like PHP, withouth being PHP :P |
|
|
In reply to this post by burtbeckwith
Em 05-01-2012 11:51, Burt Beckwith escreveu:
> Sorry for cherry-picking into a long email and a long thread, but your > Rails/Grails bug comparison is very weak. You reported two simple Rails bugs > that were each fixed with a single line of code, and are comparing these to > Grails issues that are a significantly more involved. Sorry if it looked that way, Burt. That was not my intention. I wasn't trying to compare the speed of fixing any issue by itself, but I agree with you that I didn't make myself clear enough. I was trying to say that I always get quick feedback from the Ruby/Rails community. I understand that some issues are just harder to fix than others. But one of the issues I've reported with regards to the Grails console plugin was really simple to fix (a broken CSS with a known solution) and is still unfixed... And this would probably be a single-line fix too... You might argue that this is not a priority bug to Grails and you would be right. But the ones I've reported to Rails weren't priority ones too. They're hardly used or someone would have reported them before me... Cheers, Rodrigo. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Grails development is really slow
|
I think the reason is obvious. Rails community is much bigger. Just compare [1] [2] [3] [4] [5]. It's not because rails users are more helpful than grails users. And community is just one criteria to choose a framework. [2] http://stackoverflow.com/questions/tagged/grails (5.534 questions)
|
|
|
In reply to this post by xmly
Em 05-01-2012 13:47, Gavin Yue escreveu:
I have used Grails for almost 2 years. Before I have done two project using PHP/ZendFramework. I strongly second that feeling.
And of course, I've already recommend Rails. Django doesn't use migrations by default, just like Grails. I feel this is terribly wrong. That was the main reason I've chosen Rails over Django or TurboGears back in 2007 when I was back to web programming after a long time working on embedded real-time systems with C/C++ while working on my Master thesis on Robotics. I didn't know Java, Ruby or Python at that time. Just Perl, C, C++ and Delphi mostly. So, it wouldn't matter to me to use Python or Ruby since I didn't know any of them. But I preferred the Rails approach and specially the built-in migrations. But I don't have strong experience with Django or TurboGears to give you any meaningful comparison. But I have lots of Ruby/Rails experience to recommend you that. It is much easier and faster to deploy too. And if you're using Heroku, it is just a matter of "git push heroku prod", for example. Even if you have your own servers, you can use tools like Capistrano or Chef for easily automating your deploy. Usually, I deploy my Grails application by rsyncing my war file to the server with is slower than a git push. With Rails and Passenger I would rather just git push and it would be much faster... Deploying is usually faster too. In the Java land, I had always have problems with regards to the web container reloading of apps. There will always be memory leaks and after some restarts of the application, it starts to become slower and it won't allow more restarts after a certain amount and I'll have to restart the container... Those things don't happen with Rails and Passenger, for example. Actually, they're pretty particular to the Java ecosystem. But I don't think you have much of choice since your company is a Java-based one... You shouldn't be looking for Django, I guess. Probably your best alternatives would be JRuby on Rails, Play or Grails... But I wouldn't go with Grails unless there are really Java experts in your team that understand very well the frameworks used by Grails like Spring and Hibernate. Hope to have helped... Cheers, Rodrigo.
|
|
|
In reply to this post by Danilo Tuler
Em 05-01-2012 14:11, Danilo Tuler escreveu:
>> I was trying to say that I always get quick feedback from the Ruby/Rails >> community. > I think the reason is obvious. Rails community is much bigger. > You're simplifying things. It was always responsive since I knew Rails in 2007. And it wasn't so popular those times... --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Grails development is really slow
|
As far as I know the subject of this thread is "Grails development is really slow" and not "Grails Vs Rails" as Burt said. BTW , comparing those is like Comparing peers and apples (translated from a dutch expression, don't know if it makes any sense in english) : not the same stack, not the same developer's profile , not the same clients ....
On Thu, Jan 5, 2012 at 5:50 PM, Rodrigo Rosenfeld Rosas <[hidden email]> wrote: Em 05-01-2012 14:11, Danilo Tuler escreveu: |
Re: Grails development is really slow
|
|
I love peers. I hate apples. Peers are juicier. |
«
Return to Grails - user
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |