# Running Time of R Code & Function

Understanding how long a piece of code takes to run is essential for optimizing performance, especially when dealing with computationally intensive tasks or large datasets. In R, various tools and techniques allow users to measure and analyze the execution time of scripts and functions. This article delves deep into the methods of measuring the runtime of R code, focusing primarily on the core concepts and practices.

## Introduction: Why Care About Running Time?

While R is a powerful tool for data analysis, it’s not always the fastest. Especially with the advent of big data, ensuring your code runs efficiently has become paramount. Optimized code reduces waiting times, lowers computational costs, and often signifies more streamlined and readable code.

## Basic Concepts: Big O Notation & Time Complexity

Before diving into R specifics, it’s vital to understand some basic concepts related to algorithm efficiency:

• Big O Notation: Represents the upper bound of an algorithm’s running time. It provides a high-level understanding of an algorithm’s efficiency by describing how its runtime increases as the input size grows.
• O(1): Constant time.
• O(n): Linear time.
• O(log n): Logarithmic time.

These notations provide a way to theoretically gauge the efficiency of an algorithm.

## Base R Approach: Using system.time( )

R’s base package provides system.time(), a handy function to measure the time it takes for an expression to evaluate.

Usage:

system.time(expr)

Where expr is the R expression you want to evaluate.

Understanding the Output: The result comprises three main components:

• system time: Time spent by the system on behalf of the process (e.g., memory allocation).
• elapsed time: Total time taken to execute the code. In a multi-core setup, this might be less than the sum of user and system time.

For most users, the elapsed time will be the primary interest, as it reflects the wall-clock time of the operation.

Suppose we want to measure the time it takes to generate a sequence of numbers and compute their sum.

### Step 1: Create a Task

We’ll define a simple task: generating a long sequence of numbers and then computing their sum.

long_sequence <- function() {
vec <- 1:1e7  # Create a sequence from 1 to 10 million
sum(vec)      # Compute the sum of the sequence
}

### Step 2: Measure Execution Time using system.time( )

Now, let’s measure the time it takes to execute the long_sequence function.

execution_time <- system.time(long_sequence())

### Step 3: Understand the Output

Print out the execution_time:

print(execution_time)

The output might look something like:

user  system elapsed
0.279   0.005   0.284

In our case, the function long_sequence took approximately 0.284 seconds (this can vary depending on your machine) of real-world time to execute.

The system.time() function provides a quick way to assess the duration of R expressions. It’s particularly useful for understanding the rough time consumption of tasks, enabling developers to identify potential bottlenecks or decide if more granular profiling is necessary.

## Diving Deeper with the microbenchmark Package

While system.time() gives an overview, microbenchmark offers more precise measurements, especially for short-running expressions. It evaluates an expression multiple times and provides statistical insights.

Usage: Install and load the package, then call microbenchmark() with the expressions as arguments.

Let’s use the microbenchmark package to compare the running time of two different methods for calculating the sum of the first 1,000,000 integers.

#### 1. Installation

First, if you haven’t already installed the microbenchmark package, do so:

install.packages("microbenchmark")

library(microbenchmark)

#### 3. Compare Two Methods:

We will compare two methods to calculate the sum:

• Using the built-in sum function.
• Using a simple for loop.
# Method using the sum function
method_sum <- function() {
sum(1:1e6)
}

# Method using a for loop
method_loop <- function() {
total <- 0
for(i in 1:1e6) {
total <- total + i
}
total
}

results <- microbenchmark(
sum_function = method_sum(),
for_loop = method_loop(),
times = 100  # number of times to run each method for better accuracy
)

print(results)

#### 4. Output:

When you run the above code, you’ll get an output that looks something like this (times will vary based on your machine):

Unit: nanoseconds
expr      min       lq     mean   median       uq
sum_function      300      500    15732     1400     5500
for_loop 16964000 17184150 17466019 17524250 17623500
max neval cld
1208900   100  a
19125600   100   b

The output provides min, median, mean, and max execution times, offering a more detailed insight into the variability and consistency of the code’s performance.

From the results, it’s evident that using the sum function is considerably faster than using a for loop for this task. The microbenchmark package provides a precise measurement, especially for such quick operations.

## Visualizing Execution Time with bench

The bench package not only measures execution time but also memory allocations. Its mark() function is similar to microbenchmark(), but with a more user-friendly output and visualization capabilities.

Usage: Install and load the bench package and then use the mark() function.

Let’s use the bench package to compare the running time of two operations and subsequently visualize the results with varying input sizes.

install.packages("bench")
library(bench)

# Define the two methods
method_sum <- function(n) {
sum(1:n)
}

method_loop <- function(n) {
total <- 0
for(i in 1:n) {
total <- total + i
}
total
}

# Benchmark the two methods
results <- bench::mark(
sum_function = method_sum(1e6),
for_loop = method_loop(1e6)
)
print(results)

#### Visualize with Varying Input Sizes

# Use the press function for varying input sizes
results_varying <- bench::press(
sizes = c(10, 100, 1000, 1e4, 1e5, 1e6),
bench::mark(
sum_function = method_sum(sizes),
for_loop = method_loop(sizes)
)
)

# Print the varying results
print(results_varying)

When you run the above code, you’ll get a detailed breakdown of the timings for each method and each input size. From the results, you’ll observe that using the sum function is typically much faster than the for loop, especially as the input size increases.

Additionally, the press function from the bench package allows you to quickly run benchmarks across various input sizes, making it easier to see how performance scales.

## A Look at profvis for Profiling

Beyond just measuring runtime, understanding where the code spends its time is crucial. profvis provides an interactive visualization of code profiling, showing memory and time allocations for each line.

Usage: After installing and loading the package, wrap the code you want to profile inside profvis({}).

Let’s use the profvis package to profile a piece of R code. For this example, we will profile the performance of two tasks: generating a random matrix and performing matrix multiplication.

install.packages("profvis")
library(profvis)

profvis({
# Generate a random matrix with 1000 rows and 1000 columns
matrix_a <- matrix(runif(1e6), nrow = 1000)
matrix_b <- matrix(runif(1e6), nrow = 1000)

# Perform matrix multiplication
result_matrix <- matrix_a %*% matrix_b
})

When you run the above code, a new browser window (or RStudio pane, if you’re using RStudio) will open, showing an interactive flame graph of the code’s performance. The flame graph displays which parts of the code take the most time to run, allowing you to pinpoint performance bottlenecks.

In our example, you’ll likely see that matrix multiplication (%*%) consumes a significant portion of the time. This visualization helps users understand where the most time is being spent in their R scripts or applications.

## Conclusion

Efficient code is a balance of correctness and speed. While R offers powerful tools for data analysis and visualization, it’s equally essential to ensure the code runs efficiently. By leveraging the tools and techniques discussed in this article, R users can effectively measure, analyze, and eventually optimize the runtime of their scripts and functions, ensuring swift and responsive results.

Posted in RTagged