Quantcast

Grails development is really slow

classic Classic list List threaded Threaded
109 messages Options
123456
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Lari Hotari -

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.
Do you experience this "slow" development cycle? Is it normal or is it just on my machine?

Raffaele

2012/1/5 John Fletcher-3 [via Grails] <[hidden email]>
Raffaele,
 
There have been some good but perhaps confusing suggestions on this thread. Here is what I would do - ignore the installation and everything else you already have done (you can just leave it all as is), and go to http://www.grails.org/Documentation and follow steps 1 and 2 (i.e. Installation and Quick Start), installing to C:\Grails. Once you have created the hello world app (i.e. completed sections 2.4 and 2.5), let us know whether running grails run-app in your hello world application is fast or slow. Then you and we will have further information to work from.
John
 
You're old enough to make your own decisions about the environment without me telling you what you should and shouldn't print. But if you do print, I hope this signature doesn't cause the message to go onto an additional page. Because that would be kind of stupid, wouldn't it?




If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4264886.html
To unsubscribe from Grails development is really slow, click here.
NAML



View this message in context: Re: Grails development is really slow
Sent from the Grails - user mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Lari Hotari -

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:

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.
Do you experience this "slow" development cycle? Is it normal or is it just on my machine?

Raffaele

2012/1/5 John Fletcher-3 [via Grails] <[hidden email]>
Raffaele,
 
There have been some good but perhaps confusing suggestions on this thread. Here is what I would do - ignore the installation and everything else you already have done (you can just leave it all as is), and go to http://www.grails.org/Documentation and follow steps 1 and 2 (i.e. Installation and Quick Start), installing to C:\Grails. Once you have created the hello world app (i.e. completed sections 2.4 and 2.5), let us know whether running grails run-app in your hello world application is fast or slow. Then you and we will have further information to work from.
John
 
You're old enough to make your own decisions about the environment without me telling you what you should and shouldn't print. But if you do print, I hope this signature doesn't cause the message to go onto an additional page. Because that would be kind of stupid, wouldn't it?




If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4264886.html
To unsubscribe from Grails development is really slow, click here.
NAML



View this message in context: Re: Grails development is really slow
Sent from the Grails - user mailing list archive at Nabble.com.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

rosenfeld
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

rosenfeld
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Graeme Rocher
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

burtbeckwith
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-
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Jason Davis
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Jason Davis
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

raffaele181188
+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
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





If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265612.html
To unsubscribe from Grails development is really slow, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

xmly
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

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
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





If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265612.html
To unsubscribe from Grails development is really slow, click here.
NAML



View this message in context: Re: Grails development is really slow
Sent from the Grails - user mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

raffaele181188
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]>
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

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
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





If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265612.html
To unsubscribe from Grails development is really slow, click here.
NAML



View this message in context: Re: Grails development is really slow
Sent from the Grails - user mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265909.html
To unsubscribe from Grails development is really slow, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Roberto Guerra
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
and with a good framework for webapps. Grails seemed perfect, but I expected a smoother experience..

2012/1/5 xmly [via Grails] <[hidden email]>
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

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
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





If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265612.html
To unsubscribe from Grails development is really slow, click here.
NAML



View this message in context: Re: Grails development is really slow
Sent from the Grails - user mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265909.html
To unsubscribe from Grails development is really slow, click here.
NAML



View this message in context: Re: Grails development is really slow
Sent from the Grails - user mailing list archive at Nabble.com.



--
The Journey Is The Reward.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

rosenfeld
In reply to this post by Graeme Rocher
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

xmly
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
and with a good framework for webapps. Grails seemed perfect, but I expected a smoother experience..

2012/1/5 xmly [via Grails] <[hidden email]>
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

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
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





If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265612.html
To unsubscribe from Grails development is really slow, click here.
NAML



View this message in context: Re: Grails development is really slow
Sent from the Grails - user mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265909.html
To unsubscribe from Grails development is really slow, click here.
NAML



View this message in context: Re: Grails development is really slow
Sent from the Grails - user mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

rosenfeld
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Danilo Tuler
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.
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

rosenfeld
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. 
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...

I strongly second that feeling.

Based on what you said,  I would recommend Python/Django, though Python3 is a problem.

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.



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
and with a good framework for webapps. Grails seemed perfect, but I expected a smoother experience..

2012/1/5 xmly [via Grails] <[hidden email]>
It is really hard to compare. 

But for JAVA people,  Grails should the top choice.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

rosenfeld
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Sebastien Blanc
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:

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Danilo Tuler
BTW , comparing those is like Comparing peers and apples
I love peers. I hate apples.
Peers are juicier.

-- Danilo

123456
Loading...