> > Would it be beneficial to re-factor the two components > > of NLMSA functionality, while at the same time merging the subquery > > possibility into NLMSASlice? > > I had been planning on proposing that NLMSASlice become an independent > alignment class usable in its own right, without any dependency on > NLMSA. It seems like you're proposing the same thing. NLMSASlice is > a generic container that is reasonable for modest amounts of alignment > data. I could imagine using it for other alignment classes than NLMSA. > > NLMSASlice performance will degrade in linear proportion to the amount > of data in it, so it will not scale to large amounts of data; in- > memory NLMSA is a better way of handling that case. For your desire > to "sub-query", I wonder whether this might be better served by > retrieving your initial query as an in-memory NLMSA, which would both > be very scalable in performance and provides subqueries as you wanted.
Yes, this is a great idea. Having NLMSASlice store the data it works off of as in-memory NLMSA would be a neat solution for most of my usage patterns. Of course others may need something else altogether, for instance if their slices are themselves too huge. Maybe huge slices could be stored as temporary on-disk nestedlist databases. Cheers, Alex --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to pygr-dev@googlegroups.com To unsubscribe from this group, send email to pygr-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
