Request (unless rails already does this...)
Currently with active_support it reloads the class chain at the
beginning of each incoming HTTP request.
Suggestion: reload the class chain only if a file in a lib path *has
changed*
Thoughts?
-r
--
You received this message because you are subscribed
The only way to do this in a pure Ruby way is to poll all the files in a
thread. I'm not sure if this would be more or less performant. We tried this
in Merb and people were annoyed by the constant CPU usage (3-10%) used by
polling the entire tree. Something like watchr could make this better.
If
On Sat, Jul 3, 2010 at 5:04 PM, Yehuda Katz wrote:
> The only way to do this in a pure Ruby way is to poll all the files in a
> thread. I'm not sure if this would be more or less performant. We tried this
> in Merb and people were annoyed by the constant CPU usage (3-10%) used by
> polling the ent
I'm currently working on making the reload logic pluggable.
Konstantin
On Jul 3, 2010, at 22:04 , Yehuda Katz wrote:
> The only way to do this in a pure Ruby way is to poll all the files in a
> thread. I'm not sure if this would be more or less performant. We tried this
> in Merb and people we
On Jul 3, 2010, at 22:04 , Yehuda Katz wrote:
> The only way to do this in a pure Ruby way is to poll all the files in a
> thread. I'm not sure if this would be more or less performant. We tried this
> in Merb and people were annoyed by the constant CPU usage (3-10%) used by
> polling the enti
Wouldn't that be tricky, even impossible to do right unless you
restrict the current use cases?
Say you have A < B. First request evaluates A and B.
Then you modify B, so you reload B in a second request.
If you do not reload A, its superclass points to an obsolete object.
And that's only an ex
> Wouldn't that be tricky, even impossible to do right unless you
> restrict the current use cases?
>
> Say you have A < B. First request evaluates A and B.
>
> Then you modify B, so you reload B in a second request.
>
> If you do not reload A, its superclass points to an obsolete object.
In fact
Thinking about your approach. Let me ask you a quick question (written
from my iPhone).
We have
class C
@x = X
end
First request autoloads X because of an occurrence in a file that is
not c.rb, then it autoloads C because the request needs it somewhere
else.
The AS cache at some poin
On Jul 10, 2010, at 22:19 , Xavier Noria wrote:
> class C
> @x = X
> end
>
> First request autoloads X because of an occurrence in a file that is
> not c.rb, then it autoloads C because the request needs it somewhere
> else.
>
> The AS cache at some point associates the string "X" to th
On Sun, Jul 11, 2010 at 12:45 AM, Konstantin Haase wrote:
> On Jul 10, 2010, at 22:19 , Xavier Noria wrote:
>
>> class C
>> @x = X
>> end
>>
>> First request autoloads X because of an occurrence in a file that is
>> not c.rb, then it autoloads C because the request needs it somewhere
>> e
On Jul 11, 2010, at 01:28 , Xavier Noria wrote:
> On Sun, Jul 11, 2010 at 12:45 AM, Konstantin Haase wrote:
>
>> On Jul 10, 2010, at 22:19 , Xavier Noria wrote:
>>
>>> class C
>>> @x = X
>>> end
>>>
>>> First request autoloads X because of an occurrence in a file that is
>>> not c.rb,
On Sun, Jul 11, 2010 at 10:23 AM, Konstantin Haase wrote:
>> No, everything would be wiped unconditionally. And so everything is
>> afresh later.
>
> Only if everything is unloadable. As soon as require is used somewhere or
> external code, this no longer is the case.
> Sure, this might increase
On Jul 11, 2010, at 11:49 , Xavier Noria wrote:
> I am personally fine with the current approach, it is simple and has
> not major drawbacks for me[*]. Only autoloads what is used etc. But if
> someone finds a better way to manage this it would be awesome!
Here's a write up of what I did in my fo
13 matches
Mail list logo
