{"id":46748,"date":"2023-02-11T00:00:00","date_gmt":"2023-02-11T08:00:00","guid":{"rendered":"https:\/\/griddb-linux-hte8hndjf8cka8ht.westus-01.azurewebsites.net\/blog\/pc-benchmarking-with-griddb\/"},"modified":"2025-11-13T12:56:28","modified_gmt":"2025-11-13T20:56:28","slug":"pc-benchmarking-with-griddb","status":"publish","type":"post","link":"https:\/\/griddb.net\/en\/blog\/pc-benchmarking-with-griddb\/","title":{"rendered":"PC Benchmarking with GridDB"},"content":{"rendered":"

Assume someone, either a total nerd or a large custom PC building company, would like to keep track of the performance of the gaming PCs they build. In the company’s case, this would help ensure performance between systems featuring the same components perform consistently, so they could avoid shipping out malfunctioning systems. In the nerd’s case, it would bring up the pride of having massively over engineered the solution to a non-problem.<\/p>\n

CapFrameX<\/a> is open-source software for Microsoft Windows that can track gaming performance, frames per second (FPS) and frame time, and component sensor data like CPU temperature and graphics card power consumption. When a game is running, CapFrameX can display this data, but it can also save it to a JSON file.<\/p>\n

Logging every single frame time, of course, will generate a vast amount of data. The screenshot shows that the current frame took 7.2ms to render, which means we are generating around 150 data points per second, and we want to log all of them. So if we capture 30 minutes of gameplay data, we’ll have approximately 300,000 data points.<\/p>\n

Our first step is extracting the data from the JSON files and then loading the data into an appropriate table structure in a GridDB database.<\/p>\n

The full source code for this article can be found here: Source Code<\/a><\/p>\n

Extracting CapFrameX data from JSON<\/h2>\n
\n
# The data and entire project is available for download at: \n# https:\/\/github.com\/retowyss\/pc-benchmarking-r-griddb\n\nlibrary(tidyverse)\nlibrary(jsonlite)\n\n# This is just some janitorial data wrangling\n# The function reads the data captured by CapFrameX and makes it available\n# in a easy to use format.\n# Returns a list of three things: system-info, capture-data, sensor-data\nread_capframex_json <- function(x) {\n  capframe_data <- read_json(x, simplifyVector = TRUE)\n  \n  # We need a common length for the captured sensor data because some rows\n  # are length n and some are n-k \n  common_n <- length(capframe_data$Runs$SensorData2$MeasureTime$Values[[1]])\n  \n  list(\n    info    = capframe_data$Info %>% \n      keep(~!is.null(.)) %>% \n      as_tibble(),\n    capture = as_tibble(map(capframe_data$Runs$CaptureData, ~ .[[1]])),\n    sensors = imap_dfc(capframe_data$Runs$SensorData2, function(df, names) {\n      \n      m <- length(df$Values[[1]])\n      vals <- vector(mode = typeof(df$Values[[1]]), common_n)\n      \n      # if vector is shorter, we fill last value\n      if(m < common_n) {\n        vals <- c(df$Values[[1]], rep(df$Values[[1]][m], common_n - m))\n      } else {\n        vals <- (df$Value[[1]])[1:common_n]\n      }\n      \n      res <- list()\n      # Some list names are not appropriate as tibble headers\n      n <- str_remove(str_replace_all(names, \"\/\", \"_\"), \"_\")\n      res[[n]] <- vals\n      \n      as_tibble(res)\n    })\n  )\n}\n\ncapframex_data <- read_capframex_json(\"data\/CapFrameX-DOOMEternalx64vk.exe-2.json\")<\/code><\/pre>\n<\/div>\n
For our purposes, we keep as little data as necessary, but there’s a lot more; feel free to explore.<\/p>\n
The capture data creates one data point per frame (MsBetweenPresents<\/code>), which means that the number of rows we end up with when capturing in a fixed time window is variable. However, the sensor data is polled in a relatively fixed interval (BetweenMeasureTime<\/code>) of 250ms, although we can see that there is some variation.<\/p>\n
\n
capframex_data$info %>% \n  select(Processor, GPU, SystemRam, GameName, OS, Motherboard) %>% \n  knitr::kable()<\/code><\/pre>\n<\/div>\n\n\n\n\n\n
Processor<\/th>\nGPU<\/th>\nSystemRam<\/th>\nGameName<\/th>\nOS<\/th>\nMotherboard<\/th>\n<\/tr>\n<\/thead>\n
AMD Ryzen 9 5900X<\/td>\nNVIDIA GeForce GTX 1080 Ti<\/td>\n16GB (2x8GB) 3200MT\/s<\/td>\nDoom Eternal<\/td>\nMicrosoft Windows 11 Pro Build 22000<\/td>\nGigabyte Technology Co. Ltd. B550I AORUS PRO AX<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The info table contains the PC system hardware (Processor, GPU, RAM, Motherboard) and software data (Game, Operating System).<\/p>\n
\n
capframex_data$capture %>% \n  select(TimeInSeconds, MsBetweenPresents) %>% \n  head(n = 3) %>% \n  knitr::kable()<\/code><\/pre>\n<\/div>\n\n\n\n\n\n\n\n
TimeInSeconds<\/th>\nMsBetweenPresents<\/th>\n<\/tr>\n<\/thead>\n
0.0000000<\/td>\n8.2026<\/td>\n<\/tr>\n
0.0058994<\/td>\n5.8994<\/td>\n<\/tr>\n
0.0142062<\/td>\n8.3068<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The capture tables contains performance data. The first frame recorded at time = 0 (TimeInSeconds<\/code>) took 8.2ms (MsBetweenPresents<\/code>) for the hardware to render. The second frame took 5.9ms (MsBetweenPresents<\/code>), so relative to the start of the session 0.0059 (TimeInSeconds<\/code>) seconds had passed.<\/p>\n
We call this performance data because better hardware uses less time per frame, which means it produces more frames per second (FPS) and therefore the animations in game look smoother. But perceived smoothness is not only a factor of the number of frames the hardware can render, but also affected by the variation in frame to frame time; less variation is better. So, recurring large excursions in frame times can be an indicator of performance problems even if the average frame times are good (low).<\/p>\n