I have been using xod for testing of a project, and after getting my bearings in the program and throwing together a project, I am hitting global memory limits.
It says my global variables use 115% of the memory and won’t upload.
I tried using cloud compile, and it went through without issue.
Why is the local compile not working, but the cloud compile seems to be more efficient?
Am I doing something wrong here?
Hmm… It’s possible that with cloud compilation you’re allowed to upload even overflown programs (which will cause bugs), need to check it.
BTW, some good news. I’m in progress of applying the “loop unroll” optimization which gives very promising results. RAM consumption drops several times comparing to what we have now. I hope we’ll able to complete it this month.
Sounds like some good changes are incoming.
In the mean time, is there a general consensus on project optimizations within XOD?
Not quite sure what do you mean. Everyone agrees that XOD should be fast 
Well, a perfect assembler would always be more effective than C, a perfect C would be always more effective than a higher-level language (like JS or XOD), but that’s about perfect programs. Let’s bring back a human in this story. In that scenario, I believe that eventually an average program quickly done in XOD can be more efficient than a program doing the same thing written by an average user with Arduino C++. Our purpose is making it real.
What I mean is, is there any particular design style that is better then another within xod.
Like the way you lay out the nodes, and the way you structure everything.
Is there a more optimized way of doing that?
It seems like the code I have above is quite short and pretty simple, but it is using too much memory. So it makes me afraid that any more complex code simply isn’t possible within xod.
Ah, I see what do you mean.
Not quite. The code behind writing to an SD card is large. Not because XOD is inefficient, but because it is quite complex in Arduino per se. I’m quite sure we can make it much more efficient in XOD context (and outperform vanilla Arduino) but it’s not done yet.
Also, the logic behind reading RTC is non-trivial and it takes much resources because of current XOD performance state. That’s a subject for optimization I have mentioned.
Summary, although the patch looks quite simple, the logic behind two of its nodes is not. It could be way more efficient and we’ll work toward this goal.
