Replies: 5 comments 1 reply
-
|
I think that you said: 'that CAN be mitigated by a "loading" message'. Plz share your experience on tests and the literature that shows 'this cannot be done efficiently' (the memory management, deleting variables and removing loaded modules) |
Beta Was this translation helpful? Give feedback.
-
|
The "literature" maybe was to too fancy term for micropython discussions 😁. I'm sure there's still a lot that can be optimized in this regard on Krux, but we will have to study and do more tests. |
Beta Was this translation helpful? Give feedback.
-
|
@odudex Was the RAM issue related to PSBT signing by chance? If so, then I think this issue should be reopened: #2 I noticed early on when the firmware was larger that if I signed a transaction with many inputs, I'd run out of memory. I went looking for a solution and found that embit had one: PSBTView. I believe it pages large transactions into and out of memory rather than loading the entire thing at once. We should probably switch to using it regardless... Also, something to keep in mind: the entire firmware is loaded into memory, so it's a good idea to keep it as small as possible as well. |
Beta Was this translation helpful? Give feedback.
-
|
Yes it is exactly this problem! I saw you reopened #2 👏 , this big transaction problem needs to be addressed... |
Beta Was this translation helpful? Give feedback.
-
|
On "medium size" transactions I was using to test the issue was solved for now. For further investigations, I think UR may use a lot of RAM too. Also, we could still increase heap size, couldn't we? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I need to do some profiling on the urtypes library and the UR library from Foundation Devices to see how we can improve RAM usage. Will file an issue for this |
Beta Was this translation helpful? Give feedback.
-
After an user reported having RAM issues I've been refactoring parts of the code, splitting files and loading modules "on demand", inside of functions, instead of at the header of files. Another side effect of "on demand" module loading is Krux boots faster. This approach can have some miliseconds lags during usage, but nothing annoying or, in worst case, that can't be mitigated by a "loading" message. I also would like to unload modules, specially those use only once, but tests and literature showed this cannot be done efficiently in micropython. I believe at the current state we won't have RAM issues, but I started this discussion to check if there's any other implication on the "on demand module loading" approach, collect ideas, and make contributors aware RAM should be watched closely for new features.
Beta Was this translation helpful? Give feedback.
All reactions