From: Eleanor McHugh <eleanor@...>
Date: 2007-02-16T20:08:05+09:00
Subject: Re: dRuby file transfer performance issue

On 15 Feb 2007, at 15:25, Eivind wrote:
>      def fetch(fname)
>        File.open(fname, 'r') do |fp|
>          while buf = fp.read(4096)
>            yield(buf)
>          end
>        end
>        return nil
>      end
>
>
>      def store_from(fname, there)
>        puts
>        size = there.size(fname)
>        wrote = 0
>
>        File.rename(fname, fname + '.bak') if File.exists? fname
>        File.open(fname, 'w') do |fp|
>          yield([wrote, size]) if block_given?
>          there.fetch(fname) do |buf|
>            wrote += fp.write(buf)
>            yield([wrote, size]) if block_given?
>            nil
>          end
>          fp.close
>        end
>
>        return wrote
>      end

Your slowdown is an artefact of breaking the file read and transmit  
operations down into chunks of 4096 bytes. This will cause your 600kb  
word document to be sent as 150 discrete messages across the network,  
each time incurring the cost of a disk seek and probably the cost of  
network congestion. The fact that you're running both pieces of code  
on the same machine will also add 150 additional disk seeks into the  
equation for the write process. These all incur non-deterministic  
costs based on the actual layout of the file system, task switching  
by the OS between disk operations, particular OSs disk caching  
mechanisms, etc.

If you read the entire file into memory in one chunk that will reduce  
the cost at one end, then by buffering the whole thing in memory at  
the other end until the transfer is complete you'll reduce the other  
cost. As you are probably transmitting over TCP I also wouldn't  
bother to break the file up into discrete chunks as the underlying  
transport will take care of that for you (and 4096 is very rarely an  
optimal block size: for ethernet traffic try somewhere around 1536,  
and for disk access it'll depend on the settings for the file-system  
and the physical geometry of the disk).

As a general rule of thumb, always seek to minimise the number of I/O  
operations that your code is performing if you want to avoid these  
kinds of problems. I/O is orders of magnitude slower than anything else.

Ellie


Eleanor McHugh
Games With Brains
----
raise ArgumentError unless @reality.responds_to? :reason