Open romgrk opened 5 years ago
I have heard of this technique referred to as "bring your own buffer"...It may be possible to do this. Do you have significant evidence of the performance degradation?
I can see you are using scale: 1 so that would probably be intensive across the whole length of a chromosome. You could consider using one of the other reductionLevels to make this involve less data, probably would be faster, but if you require the lowest scale then I can see that would be resource intensive.
Yes, we indeed require to use scale: 1
. We're converting bigWig files into loompy files for an implementation of the ga4gh-rnaseq API, and we need to fill a buffer with every value, and this is for multiple tracks at once so we're filling lots of buffers with lots of entries. The API also allows for returning multiple tracks of the whole bigWig file, I'm pretty sure that any saved allocation can decrease the memory-cost of the process. (speed is not an issue though, I meant performance in terms of memory)
I'll just ask a couple more questions
The purpose is compatibility with https://github.com/romgrk/node-loompy ? so it keeps it all in the js ecosystem?
Yes, we're using that module that we wrote to keep it all in JS.
For your points:
Hey,
So for performance reasons would it be possible to implement an API that doesn't allocate an object for each entry? It could look something like this: