A way to get a deeply nested sublevel in one-go

[CMCDragonkai]

Suppose I have a leveldb instance, but I want to get the sublevel that is nested 2 or 3 times deep. This seems like it currently requires one to call subleveldown n-times, once for each sublevel, but it would be nice to be able to directly acquire the deepest sublevel in one call.

[vweevers]

That's reasonable. Would only require work in the constructor.

Slightly easier to achieve in abstract-level because its db.sublevel() method has less overloads. There it could look like db.sublevel(['foo', bar']) as a shortcut for db.sublevel('foo').sublevel('bar').

[CMCDragonkai]

Yea that would be useful, I was also wondering why it requires await or a callback to create a sublevel, when sublevels are just objects, and don't involve any changes to the DB.

In some cases, I have functions that will just create iterators directly to a specific sublevel, and I'm wondering about the performance impact of creating 3/4 deep sublevels every time I call that function.

[vweevers]

I was also wondering why it requires await

It doesn't. Can you share a snippet of code where you need await?

[CMCDragonkai]

I had to do it in #109. That's the code I'm using to open sublevels: #109 (comment)

[CMCDragonkai]

Using my sublevel opener above, creating deeply nested sublevels right now costs quite a significant amount of time. My benchmarks show:

  create 1 sublevels:
    87 320 ops/s, ±0.79%   | fastest

  create 2 sublevels:
    45 325 ops/s, ±0.55%   | 48.09% slower

  create 3 sublevels:
    30 294 ops/s, ±0.39%   | 65.31% slower

  create 4 sublevels:
    22 764 ops/s, ±2.34%   | slowest, 73.93% slower

  get via sublevel:
    25 055 ops/s, ±1.36%   | 71.31% slower

  get via key path concatenation:
    54 992 ops/s, ±2.68%   | 37.02% slower

Basically it seems like db.sublevel(['foo', bar']) would be implemented efficiently as db.sublevel('foo!bar') so that the key path is just concatenated rather than creating intermediate sublevel objects.

Right now ! is not even allowed in the parameter due to #111 , so this would have be supported internal to subleveldown.