You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wanted to share benchmarks for different approaches to ensure/enforce ordering of M/Z-intensity value pairs by M/Z value in Spectrum1 objects (relates to issue #135):
I compared:
Sorting of values in R (after reading the values with mzR and before creating the Spectrum1 objects) using either method = "radix" and method = "shell".
Sorting of values in the C constructor for Spectrum1 objects (i.e. sorting values in C).
> suppressWarnings(
+onDisk<- readMSData2(files=mzf, centroided=TRUE)
+ )
Reading3670spectrafromfilePOS_C_O_001.mzMLReading3670spectrafromfilePOS_C_O_002.mzML> library(microbenchmark)
>fDataPerFile<- split(fData(onDisk), f= fData(onDisk)$fileIdx)
>BPPARAM<- SerialParam()
>## Without M/Z sorting>unsorted<-function() {
+ bplapply(fDataPerFile,
+FUN=MSnbase:::.applyFun2SpectraOfFileMulti,
+filenames= fileNames(onDisk), queue=list(),
+APPLYFUN=NULL, BPPARAM=BPPARAM)
+ }
>## With sorting in R using method = "radix">radixSortedR<-function() {
+ bplapply(fDataPerFile,
+FUN=MSnbase:::.applyFun2SpectraOfFileMultiRadixSortMz,
+filenames= fileNames(onDisk), queue=list(),
+APPLYFUN=NULL, BPPARAM=BPPARAM)
+ }
>## With sorting in R using method = "shell">shellSortedR<-function() {
+ bplapply(fDataPerFile,
+FUN=MSnbase:::.applyFun2SpectraOfFileMultiShellSortMz,
filenames= fileNames(onDisk), queue=list(),
++APPLYFUN=NULL, BPPARAM=BPPARAM)
+ }
>## With sorting performed in the C constructor>constructorSorted<-function() {
+ bplapply(fDataPerFile,
+FUN=MSnbase:::.applyFun2SpectraOfFileMulti2,
+filenames= fileNames(onDisk), queue=list(),
+APPLYFUN=NULL, BPPARAM=BPPARAM)
+ }
>>## o Compare unsorted vs radix sorted in R> microbenchmark(unsorted(), radixSortedR(),times=10)
Unit:secondsexprminlqmeanmedianuqmaxneval
unsorted() 5.826976.2254386.7690966.8596587.0585798.18795210
radixSortedR() 7.457987.8005748.9504238.53092110.01677211.58662510cldab>>## o Compare radix sorted in R vs shell sorted in R> microbenchmark(radixSortedR(), shellSortedR(), times=10)
Unit:secondsexprminlqmeanmedianuqmaxneval
radixSortedR() 7.9628238.0441558.6808468.3814788.95165210.73435610
shellSortedR() 8.1452148.5153228.8464068.7119679.2171539.99480710cldaa>>## o Compare radix sorted in R vs sorted in C constructor> microbenchmark(radixSortedR(), constructorSorted(), times=10)
Unit:secondsexprminlqmeanmedianuqmax
radixSortedR() 7.4014497.4359097.8470407.7792048.1474838.541478
constructorSorted() 6.1890336.5030436.6168896.6410966.7258567.055754nevalcld10b10a
There's no big difference, but still, the implementation in C outperforms all.
The text was updated successfully, but these errors were encountered:
o New Spectrum1_mz_sorted and Spectra1_mz_sorted functions that use
C-level constructors that enforce ordering of M/Z-intensity pairs by
M/Z.
o Unit test for new constructors (in test_Spectrum_Constructor.R).
o Cleanup of C-code.
o Benchmarks for comparison of M/Z sorting in R and in the
C-constructors (see issue #136 for results).
o Add smoothed argument to Spectrum1 constructor.
Wanted to share benchmarks for different approaches to ensure/enforce ordering of M/Z-intensity value pairs by M/Z value in
Spectrum1
objects (relates to issue #135):I compared:
mzR
and before creating theSpectrum1
objects) using eithermethod = "radix"
andmethod = "shell"
.Spectrum1
objects (i.e. sorting values in C).There's no big difference, but still, the implementation in C outperforms all.
The text was updated successfully, but these errors were encountered: