If I understand correctly, you implemented a more robust parallelization workflow on the current "logging" branch by actively triggering the java garbage collection. On first glance, this seems to effectively limit memory usage per core which is good (here no guarantees just yet as the data I used wasn't that large). However, I noticed that the actual annotation step when used as follows in the console
looks rather scary because the terminal "scrolls" through an infinitive number of invisible lines while calculating, looking like it crashed until the console prompt comes back after a while.
I didn't test progress = TRUE because this was a tricky option to use in earlier versions. But I think with progress = FALSE, the console output should be omitted somehow because this is rather irritating.
If I understand correctly, you implemented a more robust parallelization workflow on the current "logging" branch by actively triggering the java garbage collection. On first glance, this seems to effectively limit memory usage per core which is good (here no guarantees just yet as the data I used wasn't that large). However, I noticed that the actual annotation step when used as follows in the console
looks rather scary because the terminal "scrolls" through an infinitive number of invisible lines while calculating, looking like it crashed until the console prompt comes back after a while.
I didn't test
progress = TRUE
because this was a tricky option to use in earlier versions. But I think withprogress = FALSE
, the console output should be omitted somehow because this is rather irritating.