Я чаще пользуюсь foreach. Мне как-то он ближе ))

мне как-то казалось, что и так обычные *apply() функции, как и {purrr} не быстрее циклов, а немного их медленнее, потому что являются над ними обертками еще на уровне R, нет?

Если циклы правильно написаны то так и есть, но по факту никто не пишет правильные циклы

Хороший вопрос. lapply точно не медленнее циклов. В современных версиях R уже, наверное, сравнимо

А что значит «правильный цикл» кроме того, чтобы заранее создать объект нужной длины и его результатами расчетов

Некое ощущение «правильности «можно составить при прочтении: http://r-statistics.co/Strategies-To-Improve-And-Speedup-R-Code.html#1.%20Vectorize%20and%20Pre-allocate

ну, там только первый пункт про правильное использование циклов (вот как раз про preallocation, про который я говорил(, а все остальное сводится к «не используйте циклы».
При этом некоторые его варианты достаточно странные (если уж дататейбл, то зачем изменять дататейбл внутри цикла?), не говоря уже о том, что он не использует очень понятный (и, скорее всего, более быстрый, чем его варианты) способ векторизации:
system.time({df$V5 <- "lesser_than_4"
df$V5[(df$col1 + df$col2 + df$col3 + df$col4 > 4)] <- "greater_than_4"
})

Добавлю к предыдущему оратору, что параллелить код просто так не подумав - так себе затея. Можно прочесть по памяти очень быстро и иногда параллельный код бывает медленнее однопоточного

ну еще объект не создавать внутри цикла, append() не использовать, использовать which(), держать if() с наружи цикла ... наверное еще что-то есть - я не знаю ... я циклы стараюсь не писать

ктоб спорил то ))) думать и тестировать код - это хорошо, маленькая пенсия - это плохо ))

ну, опять же, это все не про правильное использование циклов, а о том, что их лучше вообще не использовать при возможности, заменяя на векторизацию где это возможно, чтоб циклы были не на самом R запущены

ладно, сдаюсь, брякнул глупость, содержательных аргументов не имею )) с любопытством послушаю другую точку зрения

Параллелить не понимая общих  принципов и специфики задачи — неблагодарное дело. Чаще всего будет хуже.

Так я о том же. Я шишек в своë время набил)) тебе другим говорю, что и на одном потоке неплохо живëтся почти всегда))

Но это не повод не открывать новые возможности :)

я вот кстати давно спрашиваю спецов: есть ли смысл при сборке пк мощнее ориентироваться на частоту процессора, а не на число ядер? А то вполне может оказаться, что какой-нибудь пентиум последних поколений с очень большой частотой будет лучше, нежели i7 с большим число ядер.

Причем нигде толком не нашел тестов либо размышлений на эту тему. А ведь для R это важная фича, когда мы говорим об однопотоке по дефолту.

Скорее всего кроме Р будет ещë что-то. Плюс запускать джобы, просто скрипты. Кажется, что 1-2 потока лучше оставить всë-таки под печатные машинки

насколько я в курсе, ориентироваться на число ядер vs частоту процессора недостаточно.

Тут очень важены еще (1) объем оперативки, (2) кэш процессора (т.е. сколько данных он сможет "заглатывать" за один раз и таким образом снижать число обращений к памяти). И еще важна (3) частота системной шины и (4) тайминги RAM - если они там как-то не совпадают, то память/процессор не синхрониризированы и часть тактов пропускают, из-за чего система немного простаивает.

У современных процессоров есть ограничения по частоте (что-то около 5Ггц), в high end сегменте особой разницы частота роли не играет, если протупить с остальными критериями.

Я просто ищу способы сэкономить на комплектующих, чтобы достичь максимума в однопотоке

Я не знаю, у вас мобильная или настольная система будет, но, грубо говоря, можно сэкономить, если взять проц с кэшем побольше, немного пожертвовав частотой и числом ядер (я на сайте интела смотрю, иногда разница в 100 баксов может быть). а эту жертву можно отчасти компенсировать более внимательным выбором матери и памяти