Do you have some proof of that statement?
Some libraries (eg. digitalWrite) can do things in a less efficient way than ones that know the pins at compile time. Sometimes there is a trade-off of ease of use vs space.
Not necessarily. Part of the problem with the digitalWrite() code isn't the flexibility.
There better are ways to implement the exact same interface
that do more at compile time and less at run time.
And there are other much faster ways to deal with the i/o in libraries even when the pins
are not constants and not known at compile time - See below.
From my perspective some of the Arduino core code appears to be written by
folks that are not very experienced with C code, using the C pre-processor to avoid runtime cycles,
or realtime programming.
However I don't know that the Arduino libraries are, per se, egregiously slow and inefficient.
I laughed out loud, but I believe you are serious.
There are many places that are just plain silly and are VERY slow compared to what can and is
done in other libraries.
I'll offer a few below.
Please supply some proofs in the form of an Arduino library compared to some other library that is much faster and less bloated. One that achieves the same things.
Ok, so here are a few.
Have a look at the shiftout() code.
The code can be made substantially faster if the code checked for
direction first then dropped down into separate loops.
Have a look at the HardwareSerial code.
It retardly uses unsigned int for the head/tail indexes.
The reason I say that this is "retarded" is that even though the code declares them
as volatile, the code will break if the values get larger than a single byte because other
parts of the code do not properly deal with atomicity.
Changing these to uint8_t makes the code faster and saves a few hundred bytes.
Nothing is lost by making this change since the code won't work right if the buffers require
larger than 8 bit values anyway.
(I make this change to every single Arduino release)
Then there is the baud rate calculation. This eats up a large amount of code because of the math.
A small table would be less flexible but would dramatically reduce the code size.
The calculation done by the non Arduino AVR-libC helper routines do all the baud calculations
at compile time instead of run time. It saves many hundreds of bytes to do it this way vs
the way the Arduino code does it.
Back to digitalWrite(), DigitalRead():
As far as digitalWrite() goes there are several implementations that are MUCH faster
when the values are constants. The Teensyduino code which uses the exact same
API interface has the best of all worlds.
It automatically will collapse the operation down to a single cycle when the arguments are constants.
I even wrote a library for constants that looks/works just like the Arduino version
and can even automagically do mutibit i/o like 8 pins at once if the pins specified are in the proper order.
Here is the link: http://code.google.com/p/mcu-io/
(see the avrio portion of the tree to get the avrio.h header file)
with a call like:
avrio_digitalWrite8pins(p0, p1, p2, p3, p4, p5, p6, p7, byteval);
With the appropriate pins and a constant byte value,
that can set all 8 pins in a single instruction vs around 40+us
This will be more than 300 times faster than the Arduino core code to
do the same operation.
My biggest beef with the Arduino core code is that it just looks so amateurish.
There are often better and faster ways to implement the code and if there was a bit
better overall design it could be made substantially better and faster.
Just to give another data point, with respect to library code.
fm's new LiquidCrytal library is a direct replacement for the LiquidCrytal
library that ships with the IDE.
The latest work on fm's new LiquidCrystal library
is getting much higher throughput to an lcd (3.5x) over a shift register using a single wire
(yes you read that correctly, a single Arduino pin) bit banging in s/w
than the standard LiquidCrystal library using 6 pins.
This is a great demonstration, that there are ways to do portable code in libraries that
live within the confines of existing arduino core code APIs, that still allow users to enter pin numbers
in constructors and yet get much higher performance.
The code in the fm's library has high speed shiftout routines that are portable across
PICkit and Arduino and it does not depend on constant pin numbers that are known
at compile time.
And as performance example,
the stock LiquidCrystal library using 6 Arduino pins in 4 bit mode
can update a 16x2 display around 86 frames per second.
When the code is simply re-factored and optimized, and still using digitalWrite() that jumps to around 300 frames per second.
With a shift register using 1 wire you can get 318 frames per second.
With a shift register using 2 wires you can get 388 frames per second.
With a shift register using 3 wires you can get 480 frame per second.
While the shift register code doesn't use digitalWrite() it is not using direct port i/o with hard coded constants.
It allows the user to specify the pins within the constructor.
This shows how poor the digitalWrite() and the LiquidCrystal library are compared
to what can be done even when the code is portable across processors.
Just re-writing/optimizing the lcd library code and still using digitalWrite(), the LCD can be driven around 3.5x faster
And then when using a shift register and fewer Arduino pins and avoiding digitalWrite():
1 pin is 3.7x faster than LiquidCrystal using 6 pins
2 pins is 4.5x faster than LiquidCrystal using 6 pins
3 pins is 5.6x faster than LiquidCrystal using 6 pins.
So yeah, right there is just one example of how "egregiously slow and inefficient"
an Arduino supplied library is compared to what can be done.
There are also inefficiencies in things like the Print class,
Then there are cases where certain classes end up getting linked in
even when not used because of the way ISRs are declared.
gcc has some capabilities that can be used to solve this.
Some libraries end up gobbling up RAM that is never used because
of the way the code is written it statically declares ram for all the instances
and it ends up being linked in again, because of the way the ISRs are declared/used.
So there are just a few examples off the top of my head.