Roger Pack wrote:

> You can test your hypothesis by running it against jruby with a 
> "constant time" GC.
> If you're using 1.9 you could also test your hypothesis by using the 
> GC::Profiler 
> http://en.wikibooks.org/wiki/Ruby_Programming/Reference/Objects/IO/GC/Profiler
> 
> Also the "exact" 5 second delays makes me wonder if it isn't a DNS 
> lookup.
> 
> Try your code with
> BasicSocket.do_not_reverse_lookup=true

Three observations:

a) I do not think that there can be a DNS lookup between a 'select(x, y, 
z)' and a 'socket.recvfrom'.

I also clarify that the 2 statements are almost sequential; after the 
select, you verify that the there is a 'read condition' and then you 
issue the 'recvfrom'. The whole section takes less than 10 lines of code 
(with printouts, etc), and it should not generate any external query.

b) for the same reason I did not need a profiler (in a real system 
moving machinery) to evaluate the time spent between those 2 statements. 
Just computing the difference between the 2 times ('Time.now' when 
select and recvfrom return), and then printing when the difference was > 
a threshold was enough.

As I said, this happened regularly (after many thousands of messages 
were exchanged with perfect timing), producing several 'processing gaps' 
of either 5 or 10 seconds every hour (approx). This occurred only when 
UDP was used over Ethernet between 2 machines (with the apps inside the 
same computer I never saw the problem).

c) I could not try jruby. Although Java may not be immune to perhaps 
similar problems (see problems found in the Android phone).

My conclusion is that dynamic allocation and deallocation of memory for 
tasks that occur every 100 msec or so  is to be minimized (if possible; 
else, move that task to a C program).

Still, more fundamentally, I think that we need a different garbage 
collector architecture for Ruby. All the games disabling/enabling Gc, 
tinkering, restructuring code, etc, are not the solution (for me).

-- 
Posted via http://www.ruby-forum.com/.