A blockchain store for embedded devices would be a plus, I'm having space problems on a 50GB VPS.
For static data compression is usually a good thing, actually a compressed representation for block and transaction data should be a milestone for the P2P network. Compress once, read many is "always" a win for space/time/energy/ect. If I'm not mistaken the LevelDB supports compression, it may already be compressed and in that case further compression makes the storage requirements larger.
Do you have any good idea for small memory embedded devices optimisation.
Bitcoind used at least 256MB memory, but many devices only have 128MB physical memory. Swap space is need but slowdown the whole system.
Yes, use mmap() instead of malloc() is how to achieve better performance.
However the first thing to note is that these figures almost always mean Address Space and NOT Memory. Memory is two, if not three, levels of indirection away from what applications see as Address Space. You can't trust these figures until you've removed shared and application object's, open files and a host of other items. There are also several cases where two or more set's of Addresses reference the same Memory, so you've got to untangle this as well. Combine that with the chance that some other process has the same Memory mapped into it's Address Space and you'll begin to see just how useless these figure are. Memory can be either physical or swap for this explanation, but Address Space is Address Space. Address Space -> kernel's page tables -> CPU/MMU's TLB -> other hardware magic that may exist, cpu cache NUMA ect -> Back-end storage and it's own magic, either capacitors, magnetic zones, or super fancy semiconductors. How so many believe so firmly that there is some 1:1 relation has always baffled me.
Most performance issue can not be solved at the system administration levels, it's almost always programming *decisions that cause performance issue.
* A nicer way to say poor programming.
With mmap() you get better control over how and where/what swapping is invoked, using buffered IO the performance should be about the same as using malloc() especially if there is enough space for what you need on a tmpfs. If not filesystem performance shouldn't get in your way anymore than swap performance. Add the new POSIX_FADV flags for managing cache and things really speed up...
POSIX_FADV_Something
POSIX_FADV_SomethingElse
POSIX_FADV_Something, for when you've downloaded or calculated something and may never need it again. If it turns out you've another request for the data use POSIX_FADV_SomethingElse to discover if it's still around, if this fails then you redownload or calculate again. I remember reading about this(lwn.net), it was an idea for Android that was accepted into mainline after being completely redesigned. The idea changed from whatever it was in Android, it was vary different, to being a system of delayed free() that solved the same problem space.
The F in FADV is for file, you'll need to use mmap() to access this feature. This was a design choice centered around the fact that tmpfs gives malloc() performance to mmap() and that this feature is usable at the filesystem layer... Kernel automagically invokes removal of the infamous "temporary internet files" when filesystem space is low.
**zram may be faster than the SD used in embedded devices,
http://en.wikipedia.org/wiki/Secure_Digital#Speeds make sure to use the fastest SD/SSD your hardware supports. Desktop and laptop systems have SSD speeds ten times greater.
** I think there is something even newer now to look forward too.
