This PR is aimed at reducing the RAM footprint of PGX computation. Basically it boils down to two changes:
Use of matrixStats for rank computation. Using apply was both slower and memory hungry. Nevertheless, this updated operation still causes a peak of RAM usage. Can be further reduced by ranking the matrix by chunks.
Assert further control on the multi-threading functionalities of fgsea and GSVA. Both this functions can take up large chunks of memory when used on a multi-threaded configuration (crashing the compute workers), for that reason, I have set them to 1 thread on most scenarios except pgx.correlateSignatureH5, where 1 thread tragically affects performance, keeping it at 2 threads provides decent enough performance and much more safe RAM usage.
These upgrades do not affect the results. Please @mauromiguelm double check on your end.
This PR is aimed at reducing the RAM footprint of PGX computation. Basically it boils down to two changes:
matrixStats
for rank computation. Usingapply
was both slower and memory hungry. Nevertheless, this updated operation still causes a peak of RAM usage. Can be further reduced by ranking the matrix by chunks.fgsea
andGSVA
. Both this functions can take up large chunks of memory when used on a multi-threaded configuration (crashing the compute workers), for that reason, I have set them to 1 thread on most scenarios exceptpgx.correlateSignatureH5
, where 1 thread tragically affects performance, keeping it at 2 threads provides decent enough performance and much more safe RAM usage.These upgrades do not affect the results. Please @mauromiguelm double check on your end.