On 12/3/06, James Edward Gray II <james / grayproductions.net> wrote:

> Of course, I still feel it is better to use the library, though I
> appear to be outnumbered in that thinking these days.

I read through the other CSV related thread that seemed that way... I
have to say, I usually don't even dip down to FasterCSV as Ruport puts
very little overhead on it, so I just use Ruport to keep my apps
looking consistent and clean.

<shrugs> Different strokes for different folks.

> > 100000.times { a.to_csv }
>
> Just FYI, that's probably the slowest way to use FasterCSV to write
> CSV, though it is my favorite too.  Here's the implementation of
> to_csv():
>
> class Array
>    # Equivalent to <tt>FasterCSV::generate_line(self, options)</tt>.
>    def to_csv(options = Hash.new)
>      FasterCSV.generate_line(self, options)
>    end
> end

I mentioned I expected to be slowest, though when I benchmarked vs.
generate_line it looks like the method call cost is lost in the noise
at high numbers of iterations

seltzer:~ sandal$ cat fcsv.rb
require "fastercsv"
a = %w[some row data]
100000.times { a.to_csv }

seltzer:~ sandal$ time ruby -rubygems fcsv.rb

real    0m11.135s
user    0m10.974s
sys     0m0.079s

seltzer:~ sandal$ time ruby -rubygems fcsv_no_shortcut.rb

real    0m11.083s
user    0m10.920s
sys     0m0.080s

seltzer:~ sandal$ cat fcsv_no_shortcut.rb
require "fastercsv"
a = %w[some row data]
100000.times { FasterCSV.generate_line a }

> As you can see, calling FasterCSV.generate_line() yourself saves a
> layer of indirection.

Yes, this is why we use it in Ruport's CSV writing implementation
rather than a call to to_csv.
(Best to avoid two layers of indirection. :) )

> If you are generating many lines and want to go as fast as possible
> with the library use one of the following:
>
> # to an IO...
> FasterCSV.open(...) do |csv|
>    csv << [...]
>    csv << [...]
>    ...
> end
>
> # to a String
> FasterCSV.generate(...) do |csv|
>    csv << [...]
>    csv << [...]
>    ...
> end

I'll keep this in mind.

> I try not too loose too much sleep over optimizations like this until
> I really need them though and I favor Array.to_csv() in my own code.

Me too. :)