We need to know how much data the UI can handle. I propose the following:
We add options to sampled to generate a large namespace. Maybe --bigdata=<num-levels>,<num-first-nodes-children> so --bigdata=5,30 would create a 5 level deep tree with the first node in each level having 30 children. so a total of 5*30=150 nodes. ( I am only giving the first node children otherwise this will turn into a geometric series and would require mounting millions of names without helping out the case anyway).
We should try to support:
Without any slow downs, a --bigdata=10,1000 namespace.
Ideally as second goal we can support `--bigdata=100,100000
and then any arbitrary size.
If option 1) is very slow, we may want to isolate the cause the the slowness as Vanadium vs UI rendering. For this I suggest we mock Vanadium in the app and and never make RPCs and return static data and see if rendering can handle it.
We need to know how much data the UI can handle. I propose the following:
sampled
to generate a large namespace. Maybe--bigdata=<num-levels>,<num-first-nodes-children>
so--bigdata=5,30
would create a 5 level deep tree with the first node in each level having 30 children. so a total of 5*30=150 nodes. ( I am only giving the first node children otherwise this will turn into a geometric series and would require mounting millions of names without helping out the case anyway).We should try to support:
--bigdata=10,1000
namespace.`--bigdata=100,100000