Re: ActionView thread safety

[Roger Pack]

> I have found adjusting the GC constant threshold in mysql.c to yield some
> benefits.
>
> Currently, for every 20 queries with results, that's a forced GC ... I have
> seen quite a few apps that
> use fire more than that per request.

Yeah I'm still scratching my head as to why they do that. Huh? Is it
so that just in case you use .query_with_result = false and don't call
.free it will free for you? I'd be in favor of taking it totally out
:) [or maybe a variable that you can set to 0 if you want it to never
call gc arbitrarily].

> The only benefit a render pipeline would have is to eliminate DB latency as
> no matter how hard one tries
> to keep DB in the controller, from time to time a belongs to reference on a
> record being rendered eg. in a loop
> still fires, and essentially blocks the rendering process.

interesting.

-=R

[Lourens Naude]

Well ... shocking ... 1000 simple results

macbook-pros-computer:mysqlplus lourens$ ruby test/gc_benchmark.rb
user system total real
With GC 0.820000 0.040000 0.860000 ( 1.207480)
Without GC 0.060000 0.040000 0.100000 ( 0.427468)

http://github.com/oldmoe/mysqlplus/commit/35d2545c17f385a9cf524bfea39606524d75c009

on branch http://github.com/oldmoe/mysqlplus/commits/with_async_validation

http://github.com/oldmoe/mysqlplus/tree/35d2545c17f385a9cf524bfea39606524d75c009/test/gc_benchmark.rb

[Aman Gupta]

Wow. Is there a big impact on memory usage with the call to rb_gc disabled?

Aman

[Lourens Naude]

Aman,

Haven't measured it yet - have a patched local Ruby able to measure GC
collections, but currently still enjoying a flying
fixture based test suite for a refreshing change.

Will look into it in a bit.

[Muhammad A. Ali]

I am also used to disabling the GC (and calling it explicitly) in lengthy rake tasks. Noticeable performance improvements that way.

[Muhammad A. Ali]

There's a very interesting GC.count in 1.9 that returns the number of times the GC was called so far. I don't have 1.9 on this machine now to test it but I recall a large count for a simple loop

[Lourens Naude]

Interesting 1.9 results as well ...

macbook-pros-computer:mysqlplus lourens$ ruby -v

ruby 1.9.0 (2008-08-26 revision 18849) [i386-darwin9.1.0]

macbook-pros-computer:mysqlplus lourens$ ruby test/gc_benchmark.rb

      user     system      total        real

With GC  0.100000   0.030000   0.130000 (  0.448824)

Without GC  0.060000   0.050000   0.110000 (  0.428099)

macbook-pros-computer:mysqlplus lourens$ ruby test/gc_benchmark.rb

      user     system      total        real

With GC  0.100000   0.030000   0.130000 (  0.465219)

Without GC  0.060000   0.050000   0.110000 (  0.437582)

[Lourens Naude]

GC stats measured ( 1.9, GC.count ) ...

macbook-pros-computer:mysqlplus lourens$ ruby test/gc_benchmark.rb

      user     system      total        real

With GC  0.090000   0.030000   0.120000 (  0.442112)

Without GC  0.060000   0.050000   0.110000 (  0.424003)

GC before ( With GC ) 1 | GC after ( With GC ) 56 | GC before ( Without GC ) 57 | GC after ( Without GC ) 57

And with Benchmark.bmbm ...

Rehearsal ----------------------------------------------

With GC      0.090000   0.030000   0.120000 (  0.438861)

Without GC   0.070000   0.050000   0.120000 (  0.421888)

------------------------------------- total: 0.240000sec

                 user     system      total        real

With GC      0.100000   0.030000   0.130000 (  0.444890)

Without GC   0.060000   0.020000   0.080000 (  0.399314)

GC before ( With GC ) 2 | GC after ( With GC ) 54 | GC before ( Without GC ) 54 | GC after ( Without GC ) 54 | GC before ( With GC ) 55 | GC after ( With GC ) 110 | GC before ( Without GC ) 111 | GC after ( Without GC ) 111

Not sure if this won't be a huge memory hog for long running processes ...

[Roger Pack]

I also experimented a little with turning off the auto-GC and it
seemed to work fine [and no longer colllect as often!] RAM didn't
grow too large [and these are with large queries]. I think the
author's original motive for having that was fear that mysql's
internal objects [whatever those might be] would grow large while
Ruby's own wouldn't [so ruby wouldn't GC and RAM would raise forever].
I don't know if this is actually the case however, because ruby, when
using the results of those queries, uses far more memory for its own
purposes [converting them into hashes, etc.] so thus already GC's
quite a bit. Also when you call result#free it frees up the memory, I
think, so...I'm still not sure why it's in there. Was the author just
afraid we wouldn't call free?

I'd still be in favor of defaulting it to never GC :)

@Lourens: re tests. If you were to run those tests within a rails
console the difference might be a lot higher [but it's good to note
that it's already faster]. I know the GC is more efficient in 1.9 [1]
but still a big issue.

Thanks!
-=R
[1] http://markmail.org/message/shwolvhhgfjvzxlo
Also note that the with_async_validation branch still errs on transactions :)

--
Thanks!
-=R