HI, saya sedang menguji
data.table_1.10.4-3 + R versi 3.4.0 (2017-04-21)
vs
data.table_1.12.2 + R versi 3.6.1 (2019-07-05)
dan perhatikan bahwa operasi gabungan hampir 2 kali lebih lambat di data.table versi baru (R?)
Saya pikir sebagian besar tergantung pada versi data.table
rm(list=ls())
library(data.table)
library(tictoc)
aa = data.table(a = seq(1,100), b = rep(0, 100))
bb = data.table(a = seq(1,100), b = rep(1, 100))
#aa[, a1 := as.character(a)]
#bb[, a1 := as.character(a)]
setindex(aa, a)
setindex(bb, a)
tic()
for(i in c(1:1000)) {
# aa[bb, b := i.b, on=.(a, a1)] # test1
aa[bb, b := i.b, on=.(a)] # test2
}
toc()
# test1
# 3.6.1: 5.5 sec with index
# 3.6.1: 6.87 sec without index
# 3.4.0: 3.02 sec (no index)
# test2
# 3.6.1: 3.82 sec with index
# 3.6.1: 4.44 sec without index
# 3.4.0: 2.48 sec (no index)
Telah menjalankan yang berikut ini:
# run_join_time.sh
echo 'hash,time' > 'join_timings.csv'
for HASH in $(git rev-list --ancestry-path 1.10.0..1.12.4 | awk 'NR == 1 || NR % 10 == 0');
do git checkout $HASH && R CMD INSTALL . && Rscript time_join.R $HASH;
done
# time_join.R
library(data.table)
library(microbenchmark)
hash = commandArgs(trailingOnly = TRUE)
aa = data.table(a = seq(1,100), b = rep(0, 100))
bb = data.table(a = seq(1,100), b = rep(1, 100))
fwrite(data.table(
hash = hash,
time = microbenchmark(times = 1000L, aa[bb, b := i.b, on=.(a)])$time
), 'join_timings.csv', append = TRUE)
Kemudian lakukan hal berikut untuk membuat plot ini
library(data.table)
times = fread('join_timings.csv')
times[ , date := as.POSIXct(system(sprintf("git show --no-patch --no-notes --pretty='%%cd' %s", .BY$hash), intern = TRUE), by = hash]
times[ , date := as.POSIXct(date, format = '%a %b %d %T %Y %z', tz = 'UTC')]
times[ , date := as.IDate(date)]
setorder(times, date)
tags = system('
for TAG in $(git tag);
do git show --no-patch --no-notes --pretty="$TAG\t%cd" $TAG;
done
', intern = TRUE)
tags = setDT(tstrsplit(tags, '\t'))
setnames(tags, c('tag', 'date'))
tags[ , date := as.POSIXct(date, format = '%a %b %d %T %Y %z', tz = 'UTC')]
tags[ , date := as.IDate(date)]
times[ , {
par(mar = c(7.1, 4.1, 2.1, 2.1))
y = boxplot(I(time/1e6) ~ date, log = 'y', notch = TRUE, pch = '.',
las = 2L, xlab = '', ylab = 'Execution time (ms)', cex.axis = .8)
x = unique(date)
idx = findInterval(tags$date, x)
abline(v = idx[idx>0L], lty = 2L, col = 'red')
text(idx[idx>0L], .7*10^(par('usr')[4L]), tags$tag[idx>0L],
col = 'red', srt = 90)
NULL
}]
Setelah memulai, saya menyadari bahwa saya dapat merampingkan ini sedikit dengan menggunakan
echo 'hash,time,date' > 'join_timings.csv'
for HASH in $(git rev-list --ancestry-path 1.10.0..1.12.4 | awk 'NR == 1 || NR % 10 == 0');
do git checkout $HASH && R CMD INSTALL . --preclean && Rscript time_join.R $HASH $(git show --no-patch --no-notes --pretty='%cd' $HASH);
done
library(data.table)
library(microbenchmark)
args = commandArgs(trailingOnly = TRUE)
hash = args[1L]
date = as.POSIXct(args[2L], format = '%a %b %d %T %Y %z', tz = 'UTC'))
aa = data.table(a = seq(1,100), b = rep(0, 100))
bb = data.table(a = seq(1,100), b = rep(1, 100))
fwrite(data.table(
hash = hash,
date = date,
time = microbenchmark(times = 1000L, aa[bb, b := i.b, on=.(a)])$time
), 'join_timings.csv', append = TRUE)
untuk menambahkan waktu komit langsung ke benchmark
Hai MichaelChirico, saya sudah membaca dua kali
tapi apa sebenarnya yang dimaksud dengan timeline dari 2016 hingga 2019? Apakah ini versi datatable?
bukan hanya versi tetapi komit khusus. izinkan saya mencoba dan menambahkan beberapa demarkasi versi, ide bagus saya lupa menambahkannya
@MichaelChirico grafik Anda terlihat sangat keren, yang hilang adalah interpretasinya :) Dengan menebak saya akan mengatakan bahwa forder paralel baru lebih lambat untuk input dengan panjang 100 daripada sebelumnya. IMO mana yang baik-baik saja, karena ini masih mikrodetik. Tentu saja layak untuk mengurangi overhead tetapi prioritasnya harus berupa pengurangan sumber daya dalam skenario penggunaan yang paling umum. Mengulang 10.000 kali dengan panjang 100 input jelas bukan salah satunya.
itu juga tebakan saya setelah melihat 1.12.0 NEWS. akan mencoba menjalankan kembali utas tunggal.
@jangorecki , jika Anda melakukan matematika sederhana itu ribuan mikrodetik yaitu milidetik
Inspirasi dari tes ini adalah proyek saya saat ini di mana saya bergabung dengan 7-8 tabel perkalian dengan 40.000 baris
Sebelum membutuhkan waktu 18 detik, setelah itu membutuhkan waktu 40 detik
Tes saya juga termasuk kunci karakter
Saya menginstal 3.6+1.12 dan kemudian memutarnya kembali ke 3.4+1.10
Saya pikir ini bukan situasi normal itu sebabnya masalah ini ada di sini
Ya grafiknya sangat mengagumkan; kita harus melakukan lebih dari ini dan mengotomatiskannya.
Tapi laporan asli membandingkan R 3.4 dengan R 3.6, yang memiliki R 3.5 di tengah. Kita tahu bahwa R 3.5 memengaruhi data.table melalui perubahan ALTREP pada fungsi REAL(), INTEGER() dari makro ke (sedikit lebih berat).
@vk111 Bisakah Anda menjalankan kembali pengujian Anda dengan v1.12.4 sekarang di CRAN. Ada yang lebih baik? Kami telah menggunakan loop luar R API untuk mengatasi R 3.5+. Sebagai langkah selanjutnya, akan sangat bagus untuk mengetahui bagaimana Anda menemukan v1.12.4. Dapatkah Anda juga memasukkan lebih banyak informasi tentang mesin Anda; misalnya sistem operasi, RAM dan jumlah CPU.
@matt , akan melakukannya
Hai @mattdowle ,
Saya telah memperbarui ke 1.12.4 (+R 3.6.1) - pada dasarnya ada angka yang sama untuk pengujian unit dan fungsi saya
Saya akan menganggap di sini hanya bergabung dengan karakter tanpa pengindeksan - sebagai patokan
Tes unit (seperti yang disebutkan dalam posting pertama)
3.6.1: 6.87 detik tanpa indeks
3.4.0: 3.02 detik (tanpa indeks)
Fungsi saya dari proyek tetap sama: 20 vs 40 detik
Ini hanya terdiri dari ~14 dt bergabung
dua tabel 30.000 baris (dt1) dan 366.000 baris (dt2)
masing-masing 15 kolom
kuncinya adalah 2 karakter dan 1 angka
dan menetapkan 7 bidang (dari dt1 ke dt2) selama bergabung
komputer saya:
Menangkan 10 64 bit
AMD A8 2.2 Ghz
RAM 8 Gb
cmd: wmic cpu dapatkan NumberOfCores, NumberOfLogicalProcessors/ Format: List
NumberOfCores=4
NumberOfLogicalProcessors=4
Terima kasih atas analisis Anda
Hai @mattdowle jadi apakah Anda mempertimbangkan ini?
Menurut git bisect
Saya baru saja menjalankan ulang, komit ini "bersalah" karena memperlambat, semoga itu dapat membantu Matt menentukan root. Bahwa itu terkait dengan forder
membuat saya relatif yakin bahwa kami telah menyematkannya dengan benar.
https://github.com/Rdatatable/data.table/commit/e59ba149f21bb35098ed0b527505d5ed6c5cb0db
Lebih tepatnya:
# run_join_time.sh
R CMD INSTALL . && Rscript time_join.R
# time_join.R
library(data.table)
library(microbenchmark)
aa = data.table(a = seq(1,100), b = rep(0, 100))
bb = data.table(a = seq(1,100), b = rep(1, 100))
summary(microbenchmark(times = 1000L, aa[bb, b := i.b, on=.(a)])$time/1e6)
Dengan dua skrip ini, dari master/HEAD
:
git checkout 1.12.0
git bisect start
git bisect bad
git bisect good 1.11.8
Kemudian pada setiap iterasi, jalankan sh run_join_time.sh
dan periksa hasilnya. Komit bad
memakan waktu kira-kira 0,9 detik per iterasi pada mesin saya, good
melakukan sekitar 0,7.
Hai Michael, terima kasih, tetapi kinerjanya menurun drastis terutama
untuk kunci karakter-Saya menyediakan unit test di posting pertama
Pokoknya saya pikir kita perlu menunggu konfirmasi dari Matt apakah sudah diperbaiki
versi baru atau tidak
Pada Kamis, 26 Des 2019 pukul 15:02, Michael Chirico [email protected]
menulis:
Menurut git membagi saya baru saja menjalankan ulang, komit ini "bersalah" untuk
pelan-pelan, semoga itu bisa membantu Matt menemukan akarnya. Itu dia
terkait dengan forder membuat saya relatif yakin kami telah menyematkannya
benar.e59ba14
https://github.com/Rdatatable/data.table/commit/e59ba149f21bb35098ed0b527505d5ed6c5cb0dbLebih tepatnya:
run_join_time.sh
INSTAL R CMD. && Rscript time_join.R
time_join.R
perpustakaan(data.tabel)
perpustakaan (microbenchmark)aa = data.tabel(a = seq(1,100), b = rep(0, 100))
bb = data.tabel(a = seq(1,100), b = rep(1, 100))ringkasan(microbenchmark(kali = 1000L, aa[bb, b := ib, pada=.(a)])$waktu/1e6)
Dengan dua skrip ini, dari master/HEAD:
git checkout 1.12.0
git membagi dua mulai
git membagi dua buruk
git membagi dua baik 1.11.8Kemudian pada setiap iterasi, jalankan sh run_join_time.sh dan periksa hasilnya. Itu
komit buruk memakan waktu sekitar 0,9 detik per iterasi di mesin saya,
komitmen yang baik tentang .7.—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Rdatatable/data.table/issues/3928?email_source=notifications&email_token=ABRM7MJQITNUZDNYV7NTIX3Q2S2ORA5CNFSM4I4ZPREKYY3PNVWWK3TUL52HS4DFVREXG43VMVBQ2ORA5CNFSM4I4ZPREKYY3PNVWWK3TUL52HS4DFVREXG43VMVBQ266VORTRPWQ06ZDEHLN5MVXH06
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABRM7MOTZRFFM2QKVFUHT6LQ2S2ORANCNFSM4I4ZPREA
.>
Salam,
Vasily Kuznetsov
@vk111 jika masalah ini tidak ditutup maka Anda dapat dengan aman menganggap masalahnya belum diperbaiki. Setiap kali kami memperbaiki sesuatu, kami menutup masalah terkait.
@vk111 Anda mungkin dapat mengurangi dengan beberapa tweak kecil menggunakan setkey
bukannya setindex
. Ini memotong tes Anda lebih dari setengahnya di komputer saya:
aa = data.table(a = seq(1,100), b = rep(0, 100))
bb = data.table(a = seq(1,100), b = rep(1, 100))
aa[, a1 := as.character(a)]
bb[, a1 := as.character(a)]
tic()
for(i in c(1:1000)) {
aa[bb, b := i.b, on=.(a, a1)] # test1 without key
}
toc()
## 4 sec elapsed
tic()
setkey(aa, a, a1)
setkey(bb, a, a1)
for(i in c(1:1000)) {
aa[bb, b := i.b] # test2 without key
}
toc()
## 1.46 sec elapsed
library(microbenchmark)
library(data.table)
aa = data.table(a = seq(1,100), b = rep(0, 100))
bb = data.table(a = seq(1,100), b = rep(1, 100))
aa[, a1 := as.character(a)]
bb[, a1 := as.character(a)]
aa_nokey = copy(aa)
bb_nokey = copy(bb)
tic()
aa_int_key = setkey(copy(aa), a)
bb_int_key = setkey(copy(bb), a)
toc()
tic()
aa_int_char = setkey(copy(aa), a, a1)
bb_int_char = setkey(copy(bb), a, a1)
toc()
int_nokey = function(dt1, dt2){
dt1[dt2, b := i.b, on=.(a)]
}
int_key = function(dt1, dt2){
dt1[dt2, b := i.b]
}
int_char_nokey = function(dt1, dt2){
dt1[dt2, b := i.b, on=.(a, a1)]
}
int_char_key = function(dt1, dt2){
dt1[dt2, b := i.b]
}
int_char_key_on = function(dt1, dt2){
dt1[dt2, b := i.b, on=.(a, a1)]
}
boxplot(
microbenchmark(
a_no_key = int_nokey(aa, bb),
a_key = int_key(aa_int_key, bb_int_key),
a_a1_no_key = int_char_nokey(aa, bb),
a_a1_key = int_char_key(aa_int_char, bb_int_char),
a_a1_key_on = int_char_key_on(aa_int_char, bb_int_char)
)
)
Hai Cole, ya saya tahu tentang setkey - saya memberikan deskripsi singkat di atas
dari proyek saya dan tidak ada tujuan 1000 bergabung - ada seperti 10-20
bergabung dan masalahnya adalah string karakter saya sangat dinamis dan saya
perlu membuat setkey setiap kali sebelum bergabung seperti 20 kali setkey dan 20
kali bergabung dan oleh karena itu keuntungan dalam waktu kurang dari 2 kali
Saya tinggal dengan 3.4.0 untuk sementara waktu sebagai solusi umum untuk situasi ini
dan mungkin bukan masalah besar untuk memperbaikinya di versi baru terutama jika
ada komit bersalah ditemukan
Omong-omong jika kita membandingkan apel dengan apel, saya pikir 3.4(1.10) akan menjadi
masih lebih cepat dari 3.6(1.12) jika saya menggunakan unit test yang sama dengan setkey untuk
kedua versi
Selamat berlibur
Pada Minggu, 29 Des 2019, 14:48 Cole Miller, [email protected] menulis:
@vk111 https://github.com/vk111 Anda mungkin dapat mengurangi dengan beberapa
tweak kecil menggunakan setkey alih-alih setindex. Ini memotong tes Anda dengan
lebih dari setengah di komputer saya:aa = data.tabel(a = seq(1,100), b = rep(0, 100))
bb = data.tabel(a = seq(1,100), b = rep(1, 100))aa[, a1 := sebagai.karakter(a)]
bb[, a1 := sebagai.karakter(a)]tik()
untuk(i dalam c(1:1000)) {
aa[bb, b := ib, on=.(a, a1)] # test1 tanpa kunci
}
tok()4 detik berlalu
tik()
setkey(aa, a, a1)
setkey(bb, a, a1)untuk(i dalam c(1:1000)) {
aa[bb, b := ib] # test2 tanpa kunci
}
tok()1,46 detik berlalu
[gambar: gambar]
https://user-images.githubusercontent.com/57992489/71557665-126d7880-2a17-11ea-8664-21a10deb47ca.pngperpustakaan (microbenchmark)
perpustakaan(data.tabel)aa = data.tabel(a = seq(1,100), b = rep(0, 100))
bb = data.tabel(a = seq(1,100), b = rep(1, 100))aa[, a1 := sebagai.karakter(a)]
bb[, a1 := sebagai.karakter(a)]aa_nokey = salin(aa)
bb_nokey = salin(bb)tik()
aa_int_key = setkey(salin(aa), a)
bb_int_key = setkey(salin(bb), a)
tok()tik()
aa_int_char = setkey(salin(aa), a, a1)
bb_int_char = setkey(salin(bb), a, a1)
tok()
int_nokey = fungsi(dt1, dt2){
dt1[dt2, b := ib, pada=.(a)]
}int_key = fungsi(dt1, dt2){
dt1[dt2, b := ib]
}int_char_nokey = fungsi(dt1, dt2){
dt1[dt2, b := ib, pada=.(a, a1)]
}int_char_key = fungsi(dt1, dt2){
dt1[dt2, b := ib]
}int_char_key_on = fungsi(dt1, dt2){
dt1[dt2, b := ib, pada=.(a, a1)]
}petak kotak(
mikrobenchmark (
a_no_key = int_nokey(aa, bb),
a_key = int_key(aa_int_key, bb_int_key),
a_a1_no_key = int_char_nokey(aa, bb),
a_a1_key = int_char_key(aa_int_char, bb_int_char),
a_a1_key_on = int_char_key_on(aa_int_char, bb_int_char)
)
)—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Rdatatable/data.table/issues/3928?email_source=notifications&email_token=ABRM7MPU64YBK7UNT3O3OYDQ3CTBRA5CNFSM4I4ZPREKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWJKLOOR5VAWZ2ZKLON5VAWSZJKOTHY56VAWSZ2J63LNMVXH
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABRM7MKSP6LCUJD2HOAG7D3Q3CTBRRANCNFSM4I4ZPREA
.
Ada PR #4370 tertunda yang terkait. Itu dapat membuat join dengan lebih sedikit overhead yang biasanya dikenakan [
. Ini mengurangi waktu contoh Anda dengan faktor 2. Semakin besar data, semakin kecil peningkatannya, tetapi di sisi lain, semakin banyak iterasi, semakin baik peningkatannya. Perhatikan bahwa tidak ada cara untuk memperbarui kolom selama bergabung. Anda pada dasarnya harus menambahkan kolom selama bergabung, dan kemudian menggunakan sesuatu seperti fcoalesce
, tetapi itu harus berkinerja baik.
Ini harus mendapatkan beberapa kecepatan ekstra setelah #4386 juga akan digabungkan.
library(data.table)
aa = data.table(a = seq(1,100), b = rep(0, 100))
bb = data.table(a = seq(1,100), b = rep(1, 100))
setindex(aa, a)
setindex(bb, a)
p = proc.time()[[3L]]
for (i in c(1:1000)) {
aa[bb, b := i.b, on=.(a)]
}
proc.time()[[3L]]-p
#[1] 1.1
daftar gabungan #4370
library(data.table)
aa = data.table(a = seq(1,100), b = rep(0, 100))
bb = data.table(a = seq(1,100), b = rep(1, 100))
setindex(aa, a)
setindex(bb, a)
p = proc.time()[[3L]]
for (i in c(1:1000)) {
mergelist(list(aa, bb), on="a")
}
proc.time()[[3L]]-p
#[1] 0.696
Hai Jan, oke terima kasih
Semakin besar data, semakin kecil peningkatannya, tetapi di sisi lain,
semakin banyak iterasi, semakin baik peningkatan
Masalah sebenarnya terkait dengan data besar dan beberapa iterasi - saya menulisnya
di atas
Pada Senin, 4 Mei 2020, 00:33 Jan Gorecki, [email protected] menulis:
Ada PR #4370 yang tertunda
https://github.com/Rdatatable/data.table/pull/4370 yang terkait. Dia
dapat membuat join dengan lebih sedikit overhead yang [ biasanya dikenakan. Ini mengurangi
waktu contoh Anda dengan faktor 2. Semakin besar data, semakin kecil
peningkatan, tetapi di sisi lain, semakin banyak iterasi, semakin baik
peningkatan. Perhatikan bahwa tidak ada cara untuk memperbarui kolom selama bergabung. Anda
pada dasarnya harus menambahkan kolom saat bergabung, dan kemudian menggunakan sesuatu seperti
fcoalesce, tapi itu harus performant.
Seharusnya mendapatkan kecepatan ekstra sekali #4386
https://github.com/Rdatatable/data.table/pull/4386 juga akan digabungkan.perpustakaan(data.tabel)aa = data.tabel(a = seq(1,100), b = rep(0, 100))bb = data.tabel(a = seq(1,100), b = rep(1, 100))
setindex(aa, a)
setindex(bb, a)p = proc.time()[[3L]]for (i in c(1:1000)) {
aa[bb, b := ib, pada=.(a)]
}
proc.time()[[3L]]-p#[1] 1.1daftar gabungan #4370 https://github.com/Rdatatable/data.table/pull/4370
perpustakaan(data.tabel)aa = data.tabel(a = seq(1,100), b = rep(0, 100))bb = data.tabel(a = seq(1,100), b = rep(1, 100))
setindex(aa, a)
setindex(bb, a)p = proc.time()[[3L]]for (i in c(1:1000)) {
mergelist(daftar(aa, bb), on="a")
}
proc.time()[[3L]]-p#[1] 0.696—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Rdatatable/data.table/issues/3928#issuecomment-623193573 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABRM7MJR5THRHE3FIXXV3YTRPXWNNANCNFSM4I4ZPREA
.
Saya memeriksa apakah #4440 (digabungkan kemarin) menyelesaikan masalah ini, tetapi tampaknya tidak. Meskipun pengaturan waktu yang saya dapatkan di sini sangat berbeda dari pengaturan waktu yang dilaporkan oleh @vk111 , jadi jika Anda dapat menguji versi pengembangan terbaru, dan lihat apakah ada perbedaan untuk alur kerja Anda yang akan membantu.
Saat Anda menggunakan Windows, ada PR lain yang tertunda yang pada akhirnya dapat membantu #4558.
Ini adalah skrip umum yang saya jalankan di setiap lingkungan:
library(data.table)
setDTthreads(2) ## vk111 has 4 cores
aa = data.table(a = seq(1,100), b = rep(0, 100))[, a1 := as.character(a)]
bb = data.table(a = seq(1,100), b = rep(1, 100))[, a1 := as.character(a)]
setindex(aa, a); setindex(bb, a)
cat("test1\n")
system.time({
for(i in c(1:1000)) {
aa[bb, b := i.b, on=.(a, a1)] # test1
}})
cat("test2\n")
system.time({
for(i in c(1:1000)) {
aa[bb, b := i.b, on=.(a)] # test2
}})
Dan ini adalah lingkungan:
docker run -it --rm r-base:3.4.0
install.packages("https://cran.r-project.org/src/contrib/Archive/data.table/data.table_1.10.4-3.tar.gz", repos=NULL)
test1
user system elapsed
0.949 0.007 0.957
test2
user system elapsed
0.864 0.000 0.864
docker run -it --rm r-base:3.6.1
install.packages("https://cran.r-project.org/src/contrib/Archive/data.table/data.table_1.12.2.tar.gz", repos=NULL)
test1
user system elapsed
2.598 0.047 1.350
test2
user system elapsed
2.092 0.016 1.062
md5-e82041eef8382e88332d077bb608b87c
docker run -it --rm r-base:3.6.1
install.packages("data.table", repos="https://Rdatatable.gitlab.io/data.table")
test1
user system elapsed
1.174 0.045 1.219
test2
user system elapsed
0.981 0.024 1.004
Hai, saya menggunakan Windows
Pada Jumat, 26 Jun 2020, 13:19 Jan Gorecki, [email protected] menulis:
Saya memeriksa apakah #4440 https://github.com/Rdatatable/data.table/pull/4440
menyelesaikan masalah ini, tetapi tampaknya tidak. Meskipun pengaturan waktu saya dapatkan
di sini sangat berbeda dari pengaturan waktu yang dilaporkan oleh @vk111
https://github.com/vk111 , jadi jika Anda dapat menguji perkembangan terkini
versi, dan lihat apakah itu membuat perbedaan untuk alur kerja Anda yang akan
bermanfaat.
Ini adalah skrip umum yang saya jalankan di setiap lingkungan:perpustakaan(data.tabel)
setDTthreads(2) ## vk111 memiliki 4 coresaa = data.table(a = seq(1,100), b = rep(0, 100))[, a1 := as.character(a)]bb = data.table(a = seq(1,100), b = rep(1, 100))[, a1 := as.karakter(a)]
setindex(aa, a); setindex(bb, a)
kucing("tes1n")
system.time({untuk(i dalam c(1:1000))) {
aa[bb, b := ib, on=.(a, a1)] # test1
}})
kucing("tes2n")
system.time({untuk(i dalam c(1:1000))) {
aa[bb, b := ib, on=.(a)] # test2
}})Dan ini adalah lingkungan:
docker run -it --rm r- base:3.4.0
install.packages("https://cran.r-project.org/src/contrib/Archive/data.table/data.table_1.10.4-3.tar.gz", repos=NULL)
tes1
sistem pengguna telah berlalu
0,949 0,007 0,957
tes2
sistem pengguna telah berlalu
0,864 0,000 0,864docker run -it --rm r- base: 3.6.1
install.packages("https://cran.r-project.org/src/contrib/Archive/data.table/data.table_1.12.2.tar.gz", repos=NULL)
tes1
sistem pengguna telah berlalu
2.598 0,047 1,350
tes2
sistem pengguna telah berlalu
2.092 0,016 1,062docker run -it --rm r- base: 3.6.1
install.packages("data.table", repos="https://Rdatatable.gitlab.io/data.table")
tes1
sistem pengguna telah berlalu
1,174 0,045 1,219
tes2
sistem pengguna telah berlalu
0,981 0,024 1,004Saat Anda menggunakan Windows, ada PR lain yang tertunda yang pada akhirnya bisa
bantuan #4558 https://github.com/Rdatatable/data.table/pull/4558 .—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Rdatatable/data.table/issues/3928#issuecomment-650126662 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABRM7MJLU3XRN5YN37ZVLALRYR727ANCNFSM4I4ZPREA
.
@vk111 Ya, persis seperti yang saya tanyakan. Jika Anda dapat memeriksa 3 konfigurasi tersebut di mesin Windows Anda dan melihat apakah ada kemajuan untuk Anda.
Tapi seperti yang saya pahami, pr untuk Windows belum digabungkan
Pada Jumat, 26 Jun 2020, 20:07 Jan Gorecki, [email protected] menulis:
@vk111 https://github.com/vk111 Ya, persis seperti yang saya tanyakan.
Jika Anda dapat memeriksa 3 konfigurasi tersebut di mesin Windows Anda dan lihat
jika ada kemajuan untuk Anda.—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Rdatatable/data.table/issues/3928#issuecomment-650320224 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABRM7MMDOCNAWARCCDRSU23RYTPVFANCNFSM4I4ZPREA
.
@vk111 #4558 sudah digabung juga
Hai Jan, saya menerima saran Anda baru-baru ini - #4419
https://github.com/Rdatatable/data.table/issues/4419 terkait dengan masalah saya
jadi saya tidak memiliki potongan kode yang tepat ini dengan karakter yang bergabung
Tapi bagaimanapun terima kasih atas peningkatan ini, saya yakin itu akan banyak membantu
orang-orang di masa depan jika Anda yakin itu memiliki kinerja yang lebih baik maka saya
kira Anda hanya harus menggabungkannya
Terima kasih
, 26 . 2020 . 20:29, Jan Gorecki [email protected] :
4440 https://github.com/Rdatatable/data.table/pull/4440 sudah
digabungkan dan membantu untuk setiap OS. #4558
https://github.com/Rdatatable/data.table/pull/4558 masih menunggu untuk
menggabungkan.—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Rdatatable/data.table/issues/3928#issuecomment-650330154 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABRM7MIN2P7BXMKG74Z7EKTRYTSIJANCNFSM4I4ZPREA
.
--
Salam,
Vasily Kuznetsov
@vk111 PR yang disebutkan sudah digabungkan. Masalahnya adalah untuk mengetahui apakah masalah ini telah diselesaikan, atau setidaknya diperbaiki. PR yang digabungkan tersebut tidak berusaha menyelesaikan masalah ini, tetapi mereka terkait sehingga mungkin dapat membantu.
Kebetulan contoh minimal yang dilaporkan awalnya tidak mengungkap masalah dengan buruk. Berdasarkan @vk111 https://github.com/Rdatatable/data.table/issues/3928#issuecomment -538681316 Saya membuat contoh yang dengan jelas menunjukkan ada masalah di sini.
install.packages("https://cran.r-project.org/src/contrib/Archive/data.table/data.table_1.10.4-3.tar.gz", repos=NULL)
install.packages("https://cran.r-project.org/src/contrib/Archive/data.table/data.table_1.12.2.tar.gz", repos=NULL)
install.packages("data.table", repos="https://Rdatatable.gitlab.io/data.table")
library(data.table)
setDTthreads(2L)
set.seed(108)
n2 = 1:366000
n1 = sample(n2, 30000)
d1=data.table(id1=paste0("id",sample(n1)), id2=paste0("id",sample(n1)), v1=n1)
d2=data.table(id1=paste0("id",sample(n2)), id2=paste0("id",sample(n2)), v2=n2)
system.time(d2[d1, v1 := i.v1, on=c("id1","id2")])
md5-e82041eef8382e88332d077bb608b87c
# 3.4.0: 1.10.4-3
user system elapsed
0.144 0.000 0.144
# 3.4.0: 1.12.2
user system elapsed
0.611 0.003 0.451
# 3.4.0: 1.12.9
user system elapsed
0.611 0.000 0.452
md5-e82041eef8382e88332d077bb608b87c
# 4.0.0: 1.10.4-3
user system elapsed
0.203 0.008 0.211
# 4.0.0: 1.12.9
user system elapsed
0.812 0.004 0.644
verbose menunjukkan bahwa sebagian besar waktu dihabiskan Calculated ad hoc index in 0.611s elapsed (0.769s cpu)
, yaitu panggilan ke forderv
dari bmerge
.
Ya persis
Tapi sepertinya tidak ada perbaikan dalam tes ini?
Pada Selasa, 30 Jun 2020, 00:45 Jan Gorecki, [email protected] menulis:
Kebetulan contoh minimal yang dilaporkan awalnya kurang terekspos
masalah. Berdasarkan @vk111 https://github.com/vk111 #3928 (komentar)
https://github.com/Rdatatable/data.table/issues/3928#issuecomment-538681316
Saya membuat contoh yang dengan jelas menunjukkan ada masalah di sini.perpustakaan(data.tabel)
setDTthreads(2L)
set.seed(108)n2 = 1:366000n1 = sample(n2, 30000)d1=data.table(id1=paste0("id",sample(n1)), id2=paste0("id",sample(n1) ), v1=n1)d2=data.table(id1=paste0("id",sampel(n2)), id2=paste0("id",sampel(n2)), v2=n2)
system.time(d2[d1, v1 := i.v1, on=c("id1","id2")])3.4.0: 1.10.4-3
sistem pengguna telah berlalu
0,144 0,000 0,1443.4.0: 1.12.2
sistem pengguna telah berlalu
0,611 0,003 0,4513.4.0: 1.12.9
sistem pengguna telah berlalu
0,611 0,000 0,4524.0.0: 1.12.9
sistem pengguna telah berlalu
0,812 0,004 0,644—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Rdatatable/data.table/issues/3928#issuecomment-651408089 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABRM7MPQHSOEGLXS625BU3TRZEKSBANCNFSM4I4ZPREA
.
Tidak ada perbaikan, ini masih menjadi masalah.
Setelah beberapa penggalian, saya menemukan hambatannya adalah panggilan ini
https://github.com/Rdatatable/data.table/blob/ba32f3cba38ec270587e395f6e6c26a80be36be6/src/forder.c#L282
melangkah lebih jauh...
loop ini bertanggung jawab untuk 60%
https://github.com/Rdatatable/data.table/blob/ba32f3cba38ec270587e395f6e6c26a80be36be6/src/forder.c#L242 -L245
dan untuk 30%
https://github.com/Rdatatable/data.table/blob/ba32f3cba38ec270587e395f6e6c26a80be36be6/src/forder.c#L252 -L258
Saya mencoba memeriksa apakah menggunakan R internal ( CHAR()
makro daripada fungsi) akan membantu di sini, tetapi itu tidak membantu.
Contoh yang lebih minimal lagi, timing forderv
saja, di R 4.0 saja
install.packages("https://cran.r-project.org/src/contrib/Archive/data.table/data.table_1.10.4-3.tar.gz", repos=NULL)
library(data.table)
setDTthreads(1L)
set.seed(108)
n2 = 1:366000
d2=data.table(id1=paste0("id",sample(n2)), id2=paste0("id",sample(n2)), v2=n2)
system.time(data.table:::forderv(d2, c("id1","id2")))
install.packages("data.table", repos="https://Rdatatable.gitlab.io/data.table")
library(data.table)
setDTthreads(1L)
set.seed(108)
n2 = 1:366000
d2=data.table(id1=paste0("id",sample(n2)), id2=paste0("id",sample(n2)), v2=n2)
system.time(data.table:::forderv(d2, c("id1","id2")))
md5-e82041eef8382e88332d077bb608b87c
# 4.0.2: 1.10.4-3
user system elapsed
0.198 0.000 0.198
# 4.0.2: 1.12.9
user system elapsed
0.393 0.000 0.392
Saya mencoba memeriksa apakah menggunakan R internal (CHAR() makro daripada fungsi) akan membantu di sini, tetapi itu tidak membantu.
Itu karena R tidak melakukan itu lagi. Dengan USE_RINTERNALS, INTEGER, REAL dan saya menganggap CHAR juga, masih merupakan fungsi inline. Dengan kata lain, manfaat (yaitu makro alih-alih fungsi) dari USE_RINTERNALS telah dihapus dalam versi terbaru dari R untuk mengizinkan ALTREP. Saya tidak percaya apakah itu makro atau fungsi atau fungsi sebaris, pada dasarnya, yang membuat perbedaan. Itulah yang dilakukan oleh R di dalam unit kerja itu. Di masa lalu, USE_RINTERNALS membuatnya menjadi makro dan itu adalah pencarian memori langsung (dereferensi array hanya memperhitungkan header vektor) itulah sebabnya lebih cepat. Itu adalah unit kerja yang sangat ringan. Saat ini, R memiliki setidaknya satu cabang untuk memeriksa ALTREP dan, bahkan dengan prediksi cabang, pekerjaan tambahan itu bertambah dan/atau mencegah pengambilan awal. Dengan kata lain, R sekarang memiliki sedikit lebih banyak kode di dalam fungsi inline ini. Saya tidak punya bukti patokan, hanya teori berdasarkan melihatnya.
Akar penyebab mungkin penghapusan cabang berikut di cradix_r
https://github.com/Rdatatable/data.table/blob/76bb569fd7736b5f89471a35357e6a971ae1d424/src/forder.c#L780 -L783
dan sekarang untuk input dengan panjang 2 tidak ada hubungan arus pendek.
Tidak jelas bagaimana menempatkan cabang itu sekarang karena fungsi telah banyak berubah dalam hal cara kerjanya.