«

On Sep 21, 2007, at 6:02 PM, 7stud -- wrote:

> Ruby gets a lot of hype as part of ROR, but everything I read leads
> me to believe that Ruby is just too slow to be practical.

I never understand this statement. It really doesn't mean anything
to me.

Too slow for what? Have you switched algorithms? It's so dang rare
that move alone doesn't eliminate all speed issues. Failing that,
have you moved the bottleneck code into a C extension? Ruby makes
this pretty painless for the very rare times that a good algorithm
won't get you all the way to what you need.

If it's just that you don't like Ruby, I would prefer you say that.
There are a couple of languages that just feel wrong to me, so I
would completely understand. But your excuse doesn't make sense, in
my opinion.

James Edward Gray II

On Sep 21, 5:02 pm, 7stud -- <dol...@excite.com> wrote:
> Gavin Kistner wrote:
> > Programming languages are a personal choice. There's no need to argue
> > about which is 'better' or 'worse'. You must decide for yourself what
> > you need to get done, what language(s) allow you to accomplish those
> > goals, and which you personally prefer.
>
> Agreed. However, I learn a new languages because I think it will help
> me write better programs. Ruby gets a lot of hype as part of ROR, but
> everything I read leads me to believe that Ruby is just too slow to be
> practical.

Too slow for what? As I said, I use it frequently at work, for a lot
of different tasks. Yes, the code generation system that I wrote takes
15 seconds to run, and if you rewrote it in C it might (I'm totally
guessing) only take 1.5 seconds to run.

But it only took me 30 minutes to write something that I would guess
(guessing) would take my very experienced C++ coworkers several hours
to write.

Using these numbers (which admittedly are totally wild-ass guesses), I
would need to run the program 600 times, and have totally lost that
productivity each time, before I would even break even. (In reality,
1.5 seconds versus 15 means very little to me for something that is
run once a week or so.) Ruby has benefited my employer - it was way
more practical to use Ruby than another language.

On Sep 21, 9:14 pm, Phrogz <phr...@mac.com> wrote:
> Using these numbers (which admittedly are totally wild-ass guesses), I
> would need to run the program 600 times, and have totally lost that
> productivity each time, before I would even break even. (In reality,
> 1.5 seconds versus 15 means very little to me for something that is
> run once a week or so.) Ruby has benefited my employer - it was way
> more practical to use Ruby than another language.

To keep the world in harmony, let me give the other side:

My company DOES employee C++ programmers. Lots of them. We work on
real-time 3D applications that need to support interactive mesh
deformation with vertex weighting using joints, in multiple windows
simultaneously. We develop high speed runtimes for 3D data on next-gen
consoles, where you can't just trade memory for speed, because cache
misses due to using more memory also lose you speed.

In this world, bit packing and high high high speed data structures
and algorithms are paramount. When a racing game is using 98% of the
limited console CPU for its own game engine and only allotting 2% for
the full updating of the 3D HUD graphics and logic, Ruby can't be used
for the runtime. It can't even be used for the minor scripting that
artists use to enhance the logic. (We use Lua for that.)

As I said originally: you need to decide what your needs are, and then
what programs can be used to accomplish those needs. Ruby cannot be
used on a PSP or Wii as a high speed runtime. If that's your goal, you
can just walk away from Ruby.

But there are gobs of other very real world problems for which Ruby is
wholly suitable, where development time is way more important than CPU
or memory efficiency. If those are your goal, I encourage you to
ignore benchmarks and comparisons with other languages. (If Ruby is
100x slower to run than language YYY, and it means that it takes 10
seconds for your entire program versus 0.1 second...do you really
care? If it saves you 20 minutes of coding? If it makes you happier
while you are doing your job?) Instead, see if it works for you.

7stud -- wrote:
> Gavin Kistner wrote:
>
>> Programming languages are a personal choice. There's no need to argue
>> about which is 'better' or 'worse'. You must decide for yourself what
>> you need to get done, what language(s) allow you to accomplish those
>> goals, and which you personally prefer.
>>
>
> Agreed. However, I learn a new languages because I think it will help
> me write better programs. Ruby gets a lot of hype as part of ROR, but
> everything I read leads me to believe that Ruby is just too slow to be
> practical.
>
>

I think "slow to be practical" is very relative, again. It helps me get
my program done extremely quickly (I don't know Python - so I can't
compare with it, but it is certainly quicker than getting it done in
assembly, C, C++ or Java) and it stays out of my way. Ruby scripts are
not part of my main job but it helps a lot in things like data
manipulation where I would use a combination of tools in the past.

For a lot of the work I do, Ruby is used for internal consumption.
Every minute saved in programming is a bonus there since internal
consumption is very technically a cost. At the same time, we are happy
to let a program run for an extra 30 seconds or even 2 minutes if it's a
one-off. If it's part of a pipeline, we can usually optimize it to meet
the needs of the pipeline. For example, we found that using the base
csv classes were much slower than using line.split(',') and since out
files were extremely predictable, we could easily switch. In other
cases, we do a C extension or just hook it up to call a C executable to
preprocess the data, etc. I think Ruby is a powerful tool in a
heterogeneous environment.

It's not the answer for every problem - but it does play really well
with others. Again, I believe we should use the best tools for the job
and there are many things that I would not/ cannot do in Ruby.

Cheers,
Mohit.
9/22/2007 | 1:59 PM.

On Sep 20, 5:02 pm, Ruby Maniac <raych...@hotmail.com> wrote:

> File.exist?(_fname) if File.delete(_fname)

This is equivalent to

if File.delete(_fname)
File.exist?(_fname)
end

That's not what you want. Furthermore, there's no need
to delete the file. If you open it in mode "wb", the
existing contents will be obliterated.

Ruby Maniac wrote:
> I am new to Ruby and I could use some expert advice as to how I can
> make this code run faster.
>
> def scramble(fname)
> f = File.new(fname, "rb")
> _fname = fname + ".scrambled"
> begin
> File.exist?(_fname) if File.delete(_fname)
> rescue
> end
> ff = File.new(_fname, "wb+")
> for l in f
> l.each_byte{|c| ff.write((c | 0x80).chr) }
> end
> f.close()
> ff.close()
> end

About 2.8 times as fast.

def scramble( fname )
_fname = fname + ".scrambled"
mask = 0x8080808080808080
data = File.open( fname, "rb" ){|f| f.read }
pad = (8 - (data.size % ) % 8
data << "p" * pad
File.open( _fname, "wb"){|ff|
array = data.unpack('Q*')
array.map!{|x| x | mask }
ff.write( array.pack('Q*')[0 ... -pad] )
}
end

Hi,

At Fri, 21 Sep 2007 07:05:10 +0900,
Ruby Maniac wrote in [ruby-talk:270110]:
> def scramble(fname)
> _fname = fname + ".scrambled"
File.new(fname, "rb") do |f|
File.new(_fname, "wb+") do |ff|
ff.write(f.read.tr("\0-\177", "\200-\377"))
end
end
> end

--
Nobu Nakada

Hi,

Sat, 22 Sep 2007 17:38:51 +0900,
Nobuyoshi Nakada wrote in [ruby-talk:270305]:
> At Fri, 21 Sep 2007 07:05:10 +0900,
> Ruby Maniac wrote in [ruby-talk:270110]:
> > def scramble(fname)
> > _fname = fname + ".scrambled"
> File.new(fname, "rb") do |f|
> File.new(_fname, "wb+") do |ff|

Sorry, these are not "new" but "open".

--
Nobu Nakada

On Sep 20, 5:02 pm, Ruby Maniac <raych...@hotmail.com> wrote:
> I am new to Ruby and I could use some expert advice as to how I can
> make this code run faster.
>
> def scramble(fname)
> f = File.new(fname, "rb")
> _fname = fname + ".scrambled"
> begin
> File.exist?(_fname) if File.delete(_fname)
> rescue
> end
> ff = File.new(_fname, "wb+")
> for l in f
> l.each_byte{|c| ff.write((c | 0x80).chr) }
> end
> f.close()
> ff.close()
> end

If you actually want speed, use a compiled language.
This FreeBasic code is about 160 times as fast and
demonstrates that using Python for any reason
whatsoever is unjustified.

Use Ruby when ease of programming is paramount;
use something like FreeBasic or LuaJIT when speed
is paramount. Never submit to Python perversion.

sub scramble( filename as string )
dim outname as string
dim as integer in_handle, out_handle, i, size
dim bytes(1 to 4096) as byte

outname = filename & ".scrambled"
in_handle = freefile
open filename for binary access read as in_handle
out_handle = freefile
open outname for binary access write as out_handle
while not eof( in_handle )
size = seek( in_handle )
get #in_handle, , bytes()
size = seek( in_handle ) - size
for i = 1 to size
bytes(i) = bytes(i) or &h80
next
put #out_handle, , bytes(1), size
wend
close
end sub

On Sep 22, 5:16 am, William James <w_a_x_...@yahoo.com> wrote:
> On Sep 20, 5:02 pm, Ruby Maniac <raych...@hotmail.com> wrote:
>
> > I am new to Ruby and I could use some expert advice as to how I can
> > make this code run faster.
>
> > def scramble(fname)
> > f = File.new(fname, "rb")
> > _fname = fname + ".scrambled"
> > begin
> > File.exist?(_fname) if File.delete(_fname)
> > rescue
> > end
> > ff = File.new(_fname, "wb+")
> > for l in f
> > l.each_byte{|c| ff.write((c | 0x80).chr) }
> > end
> > f.close()
> > ff.close()
> > end
>
> If you actually want speed, use a compiled language.
> This FreeBasic code is about 160 times as fast and
> demonstrates that using Python for any reason
> whatsoever is unjustified.
>
> Use Ruby when ease of programming is paramount;
> use something like FreeBasic or LuaJIT when speed
> is paramount. Never submit to Python perversion.
>
> sub scramble( filename as string )
> dim outname as string
> dim as integer in_handle, out_handle, i, size
> dim bytes(1 to 4096) as byte
>
> outname = filename & ".scrambled"
> in_handle = freefile
> open filename for binary access read as in_handle
> out_handle = freefile
> open outname for binary access write as out_handle
> while not eof( in_handle )
> size = seek( in_handle )
> get #in_handle, , bytes()
> size = seek( in_handle ) - size
> for i = 1 to size
> bytes(i) = bytes(i) or &h80
> next
> put #out_handle, , bytes(1), size
> wend
> close
> end sub

If that prolixity bothered you, look at a
version in the J programming language.

read =: 1!:1
write =: 1!:2
scramble =: verb define
((128 (23 b.) a. i. read <y) { a. ) write <y,'.scrambled'
)

scramble 'myfile'