Changing size of compiled sketches

LeafLabs Garden » Support » Maple IDE Support

Changing size of compiled sketches

(6 posts) (3 voices)

Started 4 years ago by StephenFromNYC
Latest reply from mbolivar

StephenFromNYC
Moderator

Hello-

I am surprised how much the size of compiled sketches varies using different releases of the Maple IDE. Here is the sketch along with the sizes of the compiled sketches (created using a Windows XP SP3 system) included as comments:

// Maple Rev 3 (Windows XP SP3)
//
// size of compiled file
//
// 11552 bytes using IDE 0.0.6 (RAM)
// 9552 bytes using IDE 0.0.7 (RAM)
// 11120 bytes using IDE 0.0.8 (RAM)
// 10832 bytes using IDE 0.0.9 (RAM)
// 10696 bytes using 2011-02-13 snapshot (RAM)
// 12504 bytes using 2011-03-17 snapshot (RAM)

#include <string.h>

void setup()
{
}

void loop()
{
delay(1000);

if (strcmp("hello", "hello") == 0)
{
SerialUSB.println("hello matches");
}
}

Should I be surprised by this amount of variation? A 20% decrease (going from 0.0.6 to 0.0.7) or a 20% increase (going from 0.0.9 to the 2011-03-17 snapshot) seems like a lot to me.

Thanks!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
mbolivar
LeafLabs

Hi Stephen,

The latest snapshot size increases are due to internal usage of snprintf() to do string formatting in the Print class.

I'll remove those changes before next release; they're too costly in Flash size to justify.

Posted 4 years ago #
StephenFromNYC
Moderator

Hello-

mbolivar, thanks for the quick explanation.

I did the simple testing to investigate the size of compiled sketches, because a sketch which fits into RAM using the February 13, 2011 snapshot suddenly was too large to fit into RAM when tested using the recent March 17, 2011 snapshot. I am glad the changes will be removed before the next IDE release.

If the following question is too scary just put it at the bottom of the LeafLabs "to do" list.

When LeafLabs is selling boards with different amounts of memory (eg. the Maple Native with more FLASH and SRAM) will you offer different versions of the libmaple code which simplify programming for the end-user? For example, on the Maple Native it might be nice to have access to improved string formatting. The extra available memory will easily accommodate a larger Print class. However, the smaller amount of memory on the Maple and Maple Native will make improved string formatting harder to fit into the Print class. Does this make sense?

Thanks again for your time!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
gbulmer
Moderator

I would much prefer LeafLabs to deliver a single common libmaple, as much as practical.
IMHO it is an end user decision to use particlar facilities, and it is Leafabs task to try to avoid charging extra costs \invisibly and unpredictably.

There are three reasons:
1. Development and testing effort is focused on one deliverable, not several.
2. Easier to migrate between boards.
3. Predictability - I'd hate to transfer a program from one board to another and get an unpredictable 'charge' for the same program simply because I used a different board. That just makes me nervous.

Of course, some functionality won't work on every board, digital to analogue conversion for example, but that need not require a different version of libmaple code. It can be handled with a #if and a #error, or something, triggered by the board type.

Some documentation or hints about functions and classes which consume significant resources would be helpful.

AFAIK, there is no obstacle to using string handling like sprintf, sscanf now, to get better string formatting.

A concern with having fancier versions of print is the potential implication that larger buffers need to be allocated. I'd like to have some choice over that. So I'd like fancier string formatting to be factored out of the core I/O. This could be into a separate class, or, as is currently available in sprintf and sscanf. I don't mind which, both are understandable.

Maybe the C++ string class works too, I haven't checked.

Posted 4 years ago #
StephenFromNYC
Moderator

Hello-

With limited time and resources I also believe the most reliable approach is for LeafLabs to develop a single libmaple.

I asked the question partly out of curiosity. I was afraid the answer might be yes!

Last year when my Maple Rev 3 arrived I tried to #include "string.h", but I was surprised by how much the compiled code grew in size. I will try using sprintf() in my next test sketch.

Thank!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
mbolivar
LeafLabs

gbulmer, Stephen,

There will only be one version of libmaple. Different boards are handled via the preprocessor. If you try to e.g. use the DAC on a Maple, you'll get compile errors, as the DAC interface only exists when you compile for the Native.

Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.