Differentiate methods/functions or fields in autocompletion for R6 class.

[Fred-Wu]

mlr3 is implemented with R6 class. However, after creating a task, all autocompletes appear to be fields. Some of them actually should be methods, such as data in the screenshot below.

Can these be differentiated within VSCode?

[Fred-Wu]

Just would like to check whether it is something easy to change?

[renkun-ken]

Currently, we write out the names() of each object in the global environment on each top-level user input. To achieve this, we'll need to not only access names() but check if each child is a function, which could be a significant overhead given the way we gather such information at the moment.

The main difference here is only accessing names() or calling typeof() with each name. Here is some benchmarking:

get_names <- function(obj) {
  names(obj)
}

get_names_and_types <- function(obj) {
  names <- names(obj)
  vapply(names, function(name) {
    typeof(obj[[name]])
  }, character(1L))
}

For an object with many elements (e.g. baseenv()), the performance difference is like

env <- baseenv()
get_names(env)
get_names_and_types(env)

microbenchmark::microbenchmark(
  get_names(env),
  get_names_and_types(env)
)

Unit: microseconds
                     expr      min        lq      mean  median        uq      max neval
           get_names(env)  598.524  655.3905  738.7634  709.28  758.0825 2769.102   100
 get_names_and_types(env) 1433.744 1519.0875 1819.3571 1733.98 1804.9030 6086.458   100

But for small objects like a typical R6 classes, the performance difference is quite significant:

tsk <- mlr3::tsk("iris")
microbenchmark::microbenchmark(
  get_names(tsk),
  get_names_and_types(tsk)
)

Unit: microseconds
                     expr      min        lq       mean    median       uq      max neval
           get_names(tsk)    1.646    2.1385    4.17186    2.7675    5.080   32.734   100
 get_names_and_types(tsk) 1662.417 1993.9890 2212.53392 2040.4430 2310.729 4910.143   100

If our environment contains many objects like this, there will be obviously a notable delay on each user input given the current session watcher mechanism.

[ElianHugh]

Have we ever looked at saving a minimal globalenv representation + decompressing extension-side? E.g., using the protobuf format

[renkun-ken]

The overhead of getting the information already seems significant. I think it might be use-able if we develop an on-demand mechanism that only access the info of a requested object, which requires two-way communication, as we discussed at #440 and #594.

[renkun-ken]

If we have a vscode interactive window suggested in #700 which is built on top of a fully managed background R session, then it seems to be easier to manage these connections and conduct on-demand operations with the R session.

[github-actions]

This issue is stale because it has been open for 365 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.