Conditional Threading Optimizer:

I went on ahead with the idea of Jump/Conditional Threading and started designing the optimizer. The objective was to replace if statments with else wherever possible and also to group together the code blocks of different if blocks if the if conditionals were same. This concept is succintly covered over here.

To see the speed-ups provided by this optimization strategy, have a look at this example:

cond_thread <- function(n) {
  evens <- 0
  evens_sum <- 0
  odds <- 0
  for (i in seq_len(n)) {
    if (i %% 2 == 0) { # same logical as next if condition (can be merged)
      evens <- evens + 1
    }
    if (i %% 2 == 0) {
      evens_sum <- evens_sum + i
    }
    if (!(i %% 2 == 0)) { # exact negation as previous if (can be an else)
      odds <- odds + 1
    }
  }
}

cond_thread_opt <- function(n) {
  evens <- 0
  evens_sum <- 0
  odds <- 0
  for (i in seq_len(n)) {
    if (i %% 2 == 0) { # merged
      evens <- evens + 1
      evens_sum <- evens_sum + i
    } else { # converted to else
      odds <- odds + 1
    }
  }
}

n <- 100000
autoplot(microbenchmark(cond_thread(n), cond_thread_opt(n)))

Memory Allocation Optimizer:

Next, I set my eyes on the Memory Pre-Allocation optimization technique. The objective here was to save the R Programmers from the sin of growing a vector in loops. In our experience, we’ve seen that vector, lists, etc are initialized often with NULL or c() out of convenience. Bothering about the size of the vectors may seem trivial to the programmer, but it has a huge impact on the performance of the script.

To see the speed-ups provided by this optimization strategy, consider this example:

mem_alloc <- function(n) {
  vec <- NULL
  for (i in seq_len(n)) {
    vec[i] <- i
  }
}

mem_alloc_opt <- function(n) {
  vec <- vector(length = n)
  for (i in seq_len(n)) {
    vec[i] <- i
  }
}

n <- 100000
autoplot(microbenchmark(mem_alloc(n), mem_alloc_opt(n)))

Fixing a critical issue:

Owing to the fantastic upkeep of the rco repository, it had almost no bugs in the optimizers, and that is no mean feat. However an issue reporting a bug was reported. The bug was that an optimizer, namely opt-dead-expr() did not function when the user used ;. Ideally, the optimizer shouldn’t have been affected by the usage of ;, but here it was, a bug, laying dormant for over 6 months.

I decided to tackle this bug head on. I created a separate branch for this bug and reproduced the bug. After lots of trials and tribulations and lots of reverse-engineering, I zeroed in one the problem. It was a problem that existed in very low-level R code. When a R script without the use of ; is parsed, then they get tokenized as something called expr but when ; was used, the parser tokenized them as an exprlist. The exsisting optimizer did not handle the case of exprlist, so I appended code that handled exprlist and then the optimizer started functioning normally irrespective of the usage of ;. This is an issue which could arise in other optimizers too, but given that, it has been solved in one optimizer, solving them in other optimizers would not prove challenging. Also, in the process of making the opt_dead_expr() optimizer work, I further bolstered the robustness of the optimizer by doubling the number of test cases that the optimizer must pass, including tests with ;.

• PR for solution of issue #107

Call for Actions:

To reduce dependencies on 3rd party applications and to promote homogeneity, we decided to go for an in-house solution for the CI/CD needs of our package, ie Github Actions. Earlier the popular choice for carrying out CI/CD operations were 3rd party applications such as Travis CI or codecov.io, but lately more and more developers and organizations had been migrating to Github Actions and we decided to follow suit. Github Marketplace wasn’t much help, as there were not much support for the R Language as compared to other languages such as Rust, Ruby, Typescript, etc. So, I went through several documentations and scarce examples and created a branch that renders a website and completes the testing that Travis used to do. We left out the code coverage as Github does not yet support badges that shows the percentage of coverage.

Acting on users’ recommendations:

One of the users of rco opened an issue, with a feature request. The request that the user asked for, is as follows:

I think it would be nifty to be able to create a report out of rco optimisers. The idea would be to analyse the whole code and return some kind of markdown / bookdown that will list all the results from the optimisers, without changing the > original code. It might be useful to analyse your own code and learn what you could do better, but also it could be use in the industry to analyse the quality of code.

While actually implementing this idea, would have been a tall order, me and my mentors discussed that, as the first iteration we could work on creating a function, which could be called to check, exactly how many files from a folder or a group of files can be optimized and which optimizer is being used there. If interested, the user could run that specific file along with the optimizers named in the output, in the rco_gui() function and see the code difference.

• PR for the reporting function