Michael,
According to my timings, here is where c() spends its time on GRanges
objects with 1 meta col:
- merging the seqinfo: 1.5%
- combining the seqnames: 5.9%
- combining the ranges: 12.4%
- combining the strand: 2%
- rbinding the mcols: 78.2%
It seems that any additional meta col
That GRanges only had one column, so I'm hoping that's not a lot of
overhead. The merging of the thousands of Seqinfo objects is probably the
issue. Any way to make that n-ary instead of a Reduce() over a binary merge?
Michael
On Tue, Jan 8, 2013 at 10:44 AM, Hervé Pagès wrote:
> Hi Dario,
>
>
Hi Dario,
On 01/06/2013 07:00 PM, Dario Strbenac wrote:
Are you asking if you can rewrite your code to work faster, or are you asking
if the BioC devs need to improve the code to be faster?
I was suggesting that maybe the c function for GRanges could be optimised.
Another would be manually
The merging of the sequence information is essentially a Reduce(). The rest
of the components are merged N-way.
Michael
On Mon, Jan 7, 2013 at 9:18 AM, Ryan C. Thompson wrote:
> With such a huge difference, I would wonder if the "c" method for GRanges
> objects is doing N-1 pairwise merges inste
With such a huge difference, I would wonder if the "c" method for
GRanges objects is doing N-1 pairwise merges instead of a single N-way
merge.
On Mon 07 Jan 2013 09:08:28 AM PST, Michael Lawrence wrote:
Would be interesting to do some profiling. Could be the merging of the
sequence info, or t
Would be interesting to do some profiling. Could be the merging of the
sequence info, or the rbind on the meta DataFrames (even with one column,
could be some overhead here).
Michael
On Mon, Jan 7, 2013 at 12:31 AM, Hahne, Florian
wrote:
> Hi Dario,
> the most efficient way to transform between
Hi Dario,
the most efficient way to transform between list-like structures of
GRanges objects and single GRanges is to use the GRangesList class in the
first place. Not sure how you came up with your initial list, but assuming
that blockRanges is already a GRangesList object, unlist(blockRanges) wi
> Are you asking if you can rewrite your code to work faster, or are you asking
> if the BioC devs need to improve the code to be faster?
I was suggesting that maybe the c function for GRanges could be optimised.
> Another would be manually splitting each GRanges objects into its components:
>
Hi Dario Strbenac,
Are you asking if you can rewrite your code to work faster, or are you
asking if the BioC devs need to improve the code to be faster? As a
first test, I would try a few alternatives to see if they are
significantly faster. One would be "unlist(GRangesList(blockRanges))".
An
