Closed m-muecke closed 2 months ago
lets's use unlist
instead of purrr::list_c
in general. for tf
, sticking to base-R as much as possible makes sense, I think, even more so if the performance is better.
not sure a general answer whether to keep names or not is possible, depends on the context. sometimes we need to keep the names I think. obviously if the names are not needed, set use.names=FALSE
.
was not aware that this makes such a huge difference in memory & time. given the sloppy way we're handling names
currently, there are probably some more optimizations like this possible...
thanks!
- lets's use
unlist
instead ofpurrr::list_c
in general. fortf
, sticking to base-R as much as possible makes sense, I think, even more so if the performance is better.- not sure a general answer whether to keep names or not is possible, depends on the context. sometimes we need to keep the names I think. obviously if the names are not needed, set
use.names=FALSE
. was not aware that this makes such a huge difference in memory & time. given the sloppy way we're handlingnames
currently, there are probably some more optimizations like this possible...thanks!
then I will open a PR adding use.names to FALSE where applicable and replace purrr::list_c()
by unlist(x, use.names = FALSE)
Using
unlist(x, use.names = FALSE)
is quite a bit faster thanunlist(x)
depending one the use-casepurrr:list_c()
is also faster. See benchmarks, also note usingrecursive = FALSE
probably negligible:Result is basically that
unlist(x, use.names = FALSE)
is always the fastest thenpurrr::list_c()
. @fabian-s do you have a preference, you were already usingpurrr::list_c(x)
in few places.Created on 2024-08-01 with reprex v2.1.1