GForce optimisation could be more smart

[jangorecki]

d = data.table(x=1:4, y=1:2)
options(datatable.verbose=TRUE)
d[, j=.(min(x)), by=y]                       ## GForce TRUE
d[, j=.(min(x), mean(x)/min(x)), by=y]       ## GForce FALSE
d[, j={.(min(x))}, by=y]                     ## GForce TRUE
d[, j={x<-x; .(min(x))}, by=y]               ## GForce FALSE
d[, j={mn<-min(x); .(mn, mean(x)/mn)}, by=y] ## GForce FALSE
options(datatable.verbose=FALSE)

all those cases could be optimised

[ben-schwen]

I think another case of this also appears in the db-benchmark (now resurrected by duckdblabs at https://github.com/duckdblabs/db-benchmark) as Q2 advanced group by

Since DT[, .(range_v1_v2=max(v1, na.rm=TRUE)-min(v2, na.rm=TRUE)), by=id3] could be rewritten using chaining.

@jangorecki is query rewriting something viable in the benchmarks or does this lead it in the wrong direction?

With current master this gives a good speedup

library(data.table)
n = 1e7
DT=data.table(v1=rnorm(n), v2=rnorm(n), id3=sample(1e4, n, TRUE))
bench::mark(
  now = DT[, .(range_v1_v2=max(v1, na.rm=TRUE)-min(v2, na.rm=TRUE)), by=id3],
  gforced = DT[, .(max(v1, na.rm=TRUE), min(v2, na.rm=TRUE)), id3][, .(range_v1_v2=V1-V2), by=id3]
)
#> Warning: Some expressions had a GC in every iteration; so filtering is disabled.
#> # A tibble: 2 × 6
#>   expression      min   median `itr/sec` mem_alloc `gc/sec`
#>   <bch:expr> <bch:tm> <bch:tm>     <dbl> <bch:byt>    <dbl>
#> 1 now           316ms    328ms      3.05    40.3MB     0   
#> 2 gforced       126ms    135ms      6.57     268MB     8.22

[jangorecki]

I would keep it as it is, benchmark also compares query syntax