Ruby On Rails with small footprint

Hi folks,
I was thinking about using Ruby On Rails to develop the web GUI for our
products. However, since these are embedded systems with few space and memory
(if compared to a desktop, at least ;-)) I wonder about a few things:

1) How small can I make RAR ? I just checked the gems and it seems
the "normal" footprint is about 5MB (without examples and docs). But this is
still too much and I think we don't everything. Has someone experience with
what's necessary and what not ? We could live with a footprint of about 2MB
and I think it's possible. (Note that I have a lot of experience in packaging
software and developing si I can also do dirty hacks and modify sources if
that's what takes it to make it this small).

2) A big concern to me is the memory footprint when uploading files (updates):
we can't afford to have a 20MB file three or four times in the memory, so
does anyone know how uploads are handled ? Can I have it streamed directly to
the disk to reduce the memory footprint ?

Thanks a lot,
  Marc

Marc Haisenko wrote:

Hi folks,
I was thinking about using Ruby On Rails to develop the web GUI for our products. However, since these are embedded systems with few space and memory (if compared to a desktop, at least ;-)) I wonder about a few things:

1) How small can I make RAR ? I just checked the gems and it seems the "normal" footprint is about 5MB (without examples and docs). But this is still too much and I think we don't everything. Has someone experience with what's necessary and what not ? We could live with a footprint of about 2MB and I think it's possible. (Note that I have a lot of experience in packaging software and developing si I can also do dirty hacks and modify sources if that's what takes it to make it this small).

2) A big concern to me is the memory footprint when uploading files (updates): we can't afford to have a 20MB file three or four times in the memory, so does anyone know how uploads are handled ? Can I have it streamed directly to the disk to reduce the memory footprint ?

Thanks a lot,
  Marc

Hi Marc,

You may want to look at Merb or Camping since those frameworks are smaller. On the other hand, as an embedded systems designer myself, I wonder if you're perhaps considering the wrong tool for the job. Of course, a lot depends on what your embedded product is, so it's still early to guess :slight_smile:

If the web GUI isn't very complex, it might be sensible to use something other than Rails. Do remember that Rails is very good for dynamic database-driven websites and not that great for general-purpose static sites, for example (of course, you know that, but it's always worth reminding).

Cheers,
Mohit.
10/18/2007 | 4:59 PM.

Marc Haisenko wrote:
> Hi folks,
> I was thinking about using Ruby On Rails to develop the web GUI for our
> products. However, since these are embedded systems with few space and

memory

> (if compared to a desktop, at least ;-)) I wonder about a few things:
>
> 1) How small can I make RAR ? I just checked the gems and it seems
> the "normal" footprint is about 5MB (without examples and docs). But this

is

> still too much and I think we don't everything. Has someone experience

with

> what's necessary and what not ? We could live with a footprint of about

2MB

> and I think it's possible. (Note that I have a lot of experience in

packaging

> software and developing si I can also do dirty hacks and modify sources if
> that's what takes it to make it this small).
>
> 2) A big concern to me is the memory footprint when uploading files

(updates):

> we can't afford to have a 20MB file three or four times in the memory, so
> does anyone know how uploads are handled ? Can I have it streamed directly

to

> the disk to reduce the memory footprint ?
>
> Thanks a lot,
> Marc
>
>

Hi Marc,

You may want to look at Merb or Camping since those frameworks are
smaller. On the other hand, as an embedded systems designer myself, I
wonder if you're perhaps considering the wrong tool for the job. Of
course, a lot depends on what your embedded product is, so it's still
early to guess :slight_smile:

If the web GUI isn't very complex, it might be sensible to use something
other than Rails. Do remember that Rails is very good for dynamic
database-driven websites and not that great for general-purpose static
sites, for example (of course, you know that, but it's always worth
reminding).

Cheers,
Mohit.
10/18/2007 | 4:59 PM.

I'm already considering Camping, but Rails has the advantage of a lot of good
documentation (books) available. A colleague and I already know Rails, so
Rails would be the preferred solution because of the information available.

Our current GUI is a hand-crafted framework with C++ (using the CCGI library)
which is a good (fast) solution for an embedded system but maintaining it
just becomes more and more time consuming and we still can't do a lot of
things we'd like to do. So we now spend more time on maintaining our
framework than actually working on the GUI which is why we start to think
about moving to some established framework. Since we already have Ruby and
activerecord on some products it would just make sense to use Rails :slight_smile:

  Marc

Hi folks,
I was thinking about using Ruby On Rails to develop the web GUI for
our
products. However, since these are embedded systems with few space
and memory
(if compared to a desktop, at least ;-)) I wonder about a few things:

1) How small can I make RAR ? I just checked the gems and it seems
the "normal" footprint is about 5MB (without examples and docs).
But this is
still too much and I think we don't everything. Has someone
experience with
what's necessary and what not ? We could live with a footprint of
about 2MB
and I think it's possible. (Note that I have a lot of experience in
packaging
software and developing si I can also do dirty hacks and modify
sources if
that's what takes it to make it this small).

Well a base export of trunk is currently 6.5 megs. SInce you're just
a web gui you can junk docs, examples and the test suites, which gets
me down to 4,4 megs.
I'm guess since you;re a web gui you can do without activeresource,
actionwebservice, actionmailer.
You can also lose the changelogs and readmes
There's some stuff you're not going need. eg generators, that can
also go, and stuff for doing things like installing a plugin

If you're not going to be using prototype, ajax etc... you can get
rid of the javascrpts. Even if you are, they're their in 2 places, so
you should be able to get rid of one

You can junk the database adapters you don't need, the support for
the dispatch mechanisms you won;t need.
There are also quite a few files in railties which are just
templates: you don't need them if you're not generating new apps
Having done all that, I'm down to 2.5 megs (occupying 3.3 on disk,
what with a lot of the files being smalling the the min file size on
my filesystem). Beyund that, the biggest win would be getting rid of
the unicode tables (640k), if you don't need that. Not sure how easy
it is to removve that though.

There are a lot of comments in the source (since that's what all the
rdoc) is generated from. Removing that gets me down to 1.7 megs, 2.6
megs occupied on disk. If you can junk the unicode table then you're
home and dry.

2) A big concern to me is the memory footprint when uploading files
(updates):
we can't afford to have a 20MB file three or four times in the
memory, so
does anyone know how uploads are handled ? Can I have it streamed
directly to
the disk to reduce the memory footprint ?

Don't know anything about that.

Fred

Well a base export of trunk is currently 6.5 megs. SInce you're just
a web gui you can junk docs, examples and the test suites, which gets
me down to 4,4 megs.
I'm guess since you;re a web gui you can do without activeresource,
actionwebservice, actionmailer.
You can also lose the changelogs and readmes
There's some stuff you're not going need. eg generators, that can
also go, and stuff for doing things like installing a plugin

If you're not going to be using prototype, ajax etc... you can get
rid of the javascrpts. Even if you are, they're their in 2 places, so
you should be able to get rid of one

You can junk the database adapters you don't need, the support for
the dispatch mechanisms you won;t need.
There are also quite a few files in railties which are just
templates: you don't need them if you're not generating new apps
Having done all that, I'm down to 2.5 megs (occupying 3.3 on disk,
what with a lot of the files being smalling the the min file size on
my filesystem). Beyund that, the biggest win would be getting rid of
the unicode tables (640k), if you don't need that. Not sure how easy
it is to removve that though.

That's a lot of good pointers, thanks a lot. Sounds like my guess that it's
possible to get down to 2 MB was not that wrong :slight_smile:

There are a lot of comments in the source (since that's what all the
rdoc) is generated from. Removing that gets me down to 1.7 megs, 2.6
megs occupied on disk. If you can junk the unicode table then you're
home and dry.

Hmmm, while this is a good idea technology-wise it might be a bad idea
license-wise... need to have a look.

Thank you for the feedback.
  Marc

With the cost of micro-sd cards plumenting, I think rails would be
great for
a device interface, as well as a central management system.

and with just ruby you do alot of other things.

For updates, you should be able to use gem to pull down updates from a
custom respository.
And gem can pull it into your local flash file system. The inmemory
can be minimized.

I'm planning on doing a rails gui on a avr32 system under linux.

Dont see alot of issues on license.

glennswest wrote:

With the cost of micro-sd cards plumenting, I think rails would be
great for
a device interface, as well as a central management system.

and with just ruby you do alot of other things.

For updates, you should be able to use gem to pull down updates from a
custom respository.
And gem can pull it into your local flash file system. The inmemory
can be minimized.

I'm planning on doing a rails gui on a avr32 system under linux.

Dont see alot of issues on license.
  
This thread does seem interesting to me. As an embedded systems guy myself, I wonder what you feel about the performance and memory consumption of Ruby. For what it's worth, Toshiba seems to think that Ruby is a good way to go on the Cell processor!

http://techon.nikkeibp.co.jp/english/NEWS_EN/20071010/140438/

Cheers,
Mohit.
10/25/2007 | 7:25 PM.