Good or best way to allocate a large array

[Ralph Shnelvar]

MLK> Ralph Shnelvar wrote:
MLK> [...]
MLK> You could have found it in about 5 seconds with Google. Please try that
MLK> before posting in future.

I am new to Ruby.

There are/were indications that this is an incmoplete project.

Indeed, as a newbie, I attempted to install/expand the tar file and
could not get the installation to work.

Hence, my request which I had hoped would point me at the most recent
information.

 

[Marnen Laibow-Koser]

MLK> Ralph Shnelvar wrote:
MLK> [...]
MLK> You could have found it in about 5 seconds with Google. Please try
that
MLK> before posting in future.

I am new to Ruby.

But not to Google, surely.

There are/were indications that this is an incmoplete project.

Indeed, as a newbie, I attempted to install/expand the tar file and
could not get the installation to work.

Hence, my request which I had hoped would point me at the most recent
information.

Then you probably would have received more helpful answers if you had
said that -- without that context, most people would just point you to
the obvious docs where you'd already been.

Please include all relevant information when asking for help. You'll
get better answers if you do that.

Best,

 

[bwv549]

There are/were indications that this is an incmoplete project.

Some of the docs do make it look this way, but I think most who have
used it would agree that narray is quite mature. For what it does, it
seems to be very complete and very robust, and it has been around a
long time and seen much use.

I have used it as a gem and built it from source on many different
machines with no trouble at all. It's one of the few gems requiring
compilation I wouldn't hesitate using for any cross-platform project
since it has no dependencies to speak of and seems to compile without
a hitch every time. I'd be happy to help if you want to email me
personally.

 

[Brian Candler]

Of course, I could use a hash ... but I doubt that a hash would beat
my binary search ... I could be wrong about this.

You are almost certainly wrong about this. Ruby Hash implementation is
in C and very efficient. I'm sure this would be the quickest way to find
the row with a given key.

The array is more-or-less static. That is, access
to this array swamps any changes to the array.

Especially good for a hash.

So my advice is: write it the simplest possible way first. Then analyse
(a) the speed, and/or (b) the memory usage, if they are problematic.

There's a difference between "quickest" and "quick enough". If you were
looking for "quickest" you wouldn't be using Ruby in the first place.
But if you value your development time, you could implement this with a
Hash in 10 minutes.

300K rows and 20 columns

If those are values that fit in a Fixnum then that's only 24MB in total
on a 32-bit machine, or 48MB on a 64-bit machine. So just do the
obvious. If a few of those values are Bignums, no big deal.

If you need better packing, you can always just allocate packed strings.
For example, you can pack 20 32-bit integers (signed or unsigned) into
an 80 byte string, and unpack the row again later. Look at Array#pack
and String#unpack

 

[Albert Schlef]

[...] there's no reason to do this. Use a database. Even a
file-based DB like SQLite will make your life easier.

What a great idea. I suggest we email all the image-processing
developers and suggest them to use an RDBM instead of memory arrays.