Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limitation (max elements in list) #3

Closed
jleni opened this issue Jun 19, 2020 · 8 comments
Closed

Limitation (max elements in list) #3

jleni opened this issue Jun 19, 2020 · 8 comments
Assignees
Labels
ExternalDep External dependency

Comments

@jleni
Copy link
Member

jleni commented Jun 19, 2020

Due to memory constraints, we have limited the number of:

  • list elements
  • tuple elements

#1 (comment)

Can you confirm that this limit is acceptable? or please suggest a number that would be adequate.

@jleni jleni added the ExternalDep External dependency label Jun 19, 2020
@kantai
Copy link

kantai commented Jun 23, 2020

This wouldn't be acceptable -- there are likely to be transactions involving much larger lists and tuples. However, it would be acceptable to do something like display 'list of length X with elements of type Y' for large lists and tuples.

@jleni
Copy link
Member Author

jleni commented Jun 23, 2020

We have limitations on the amount of RAM (~2kB) and NVRAM (~8kB) in Nano S. For this reason, we need to set some maximum values. In multiple places, we are already pre-parsing and indexing and later parsing on demand as the user navigates the information. Still, we we need to set some limits and see if we can fit them.

Nano X can definitely have higher limits (~38kB RAM).

What would you suggest as an acceptable limit that still is useful in 90% of the cases?

@kantai
Copy link

kantai commented Jun 23, 2020

What's running out of memory in the parser here? Is it the parser itself? Or is the object being constructed too large? I think it should be possible to address this by not parsing large lists/tuples, and instead providing some kind of stand-in/summary value for the large object.

@jleni
Copy link
Member Author

jleni commented Jun 23, 2020

Well, it is a combination of all those.. we need to balance storage, call stack consumption plus work out a way to format and present the information.

Yes, we normally do all these things and many other tricks and somersault.. :)

I think the point is: we try to concentrate the effort in areas that are required. We were not sure what was the value we need to target. Having a number if mind helps to see how/where to spend more time and if we need to use some more complex approaches.

@kantai
Copy link

kantai commented Jun 23, 2020

I see -- I think a limit of ~10 is more reasonable and would handle most cases, however, I think an error path that still allows a user to sign more complex transactions while possibly eliding some information from the prompts is preferable to a hard error.

@jleni
Copy link
Member Author

jleni commented Jul 22, 2020

@neithanmo Can we document here the limits of the latest release?
I think we can then close this issue

@jleni
Copy link
Member Author

jleni commented Feb 20, 2021

@kantai @kyranjamie Can we close this?
I think the current limit has been acceptable in practice, right?

@neithanmo
Copy link
Collaborator

We do not have any limit here regarding the list, other than the number of the nested lists it may contain..that limit is 3 at the moment, but it can be increased if needed..

@jleni jleni closed this as completed Feb 23, 2021
ftheirs pushed a commit that referenced this issue Nov 22, 2021
Update to version 0.13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ExternalDep External dependency
Projects
None yet
Development

No branches or pull requests

3 participants