Data.table: bergabung dengan operasi hampir 2 kali lebih lambat

Dibuat pada 2 Okt 2019  ·  29Komentar  ·  Sumber: Rdatatable/data.table

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)
High joins performance regression

Semua 29 komentar

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

Screenshot 2019-10-03 at 6 59 11 PM

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

join_timings.txt

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/e59ba149f21bb35098ed0b527505d5ed6c5cb0db

Lebih 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.8

Kemudian 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

image

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.png

perpustakaan (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.1

daftar 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,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)
tes1
sistem pengguna telah berlalu
2.598 0,047 1,350
tes2
sistem pengguna telah berlalu
2.092 0,016 1,062

docker 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,004

Saat 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
.

4440 sudah digabungkan dan membantu untuk setiap OS. #4558 masih menunggu untuk digabungkan.

@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,144

3.4.0: 1.12.2

sistem pengguna telah berlalu
0,611 0,003 0,451

3.4.0: 1.12.9

sistem pengguna telah berlalu
0,611 0,000 0,452

4.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.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat