DEV Community: Dmitriy Nesteryuk

Grape: The cost of ActiveSupport::HashWithIndifferentAccess

Dmitriy Nesteryuk — Sun, 08 Dec 2019 15:43:26 +0000

By default Grape uses ActiveSupport::HashWithIndifferentAccess as a parameter builder. The most important thing about ActiveSupport::HashWithIndifferentAccess is that symbols are mapped to strings when used as keys.

So, if your routers refer to parameters by using symbols, keys get converted to strings. Let's see how it affects memory.

require 'ruby-prof'
require 'grape'

class API < Grape::API
  prefix :api
  version 'v1', using: :path

  params do
    requires :address, type: Hash do
      requires :street, type: String
      requires :postal_code, type: Integer
      optional :city, type: String
    end
  end

  post '/' do
    declared = declared(params)
    declared[:address][:street]
  end
end

options = {
  method: 'POST',
  params: {
    address: {
      street: 'Test Street',
      postal_code: '90698',
      city: 'Imagine'
    }
  }
}

env = Rack::MockRequest.env_for('/api/v1', options)

# warm up
API.call env

RubyProf.measure_mode = RubyProf::MEMORY

result = RubyProf.profile do
  API.call env
end

printer = RubyProf::FlatPrinter.new(result)
printer.print(STDOUT, min_percent: 1)

For profiling Grape 1.2.5 and Ruby 2.6.3 were used. Results:

Measure Mode: memory
Thread ID: 47373520927160
Fiber ID: 47373526155200
Total: 41112.000000
Sort by: self_time

 %self      total      self      wait     child     calls  name
 13.66   9304.000  5616.000     0.000  3688.000       18  *Hash#each_pair
 10.70  12648.000  4400.000     0.000  8248.000       29  *Class#new
  8.68   5088.000  3568.000     0.000  1520.000        8  *Array#map
  5.64   2320.000  2320.000     0.000     0.000       58   Symbol#to_s
  5.08   2088.000  2088.000     0.000     0.000        9   Hash#merge

According to the Ruby-prof doc, the total represents a number of bytes. Let's try another builder which only supports symbols.

Grape.configure do |config|
  config.param_builder = Grape::Extensions::Hash::ParamBuilder
end

Results:

Measure Mode: memory
Thread ID: 47077831236000
Fiber ID: 47077836608980
Total: 33328.000000
Sort by: self_time

 %self      total      self      wait     child     calls  name
 11.28   5736.000  3760.000     0.000  1976.000        7   Hash#each_pair
 10.71   5088.000  3568.000     0.000  1520.000        8  *Array#map
  6.94   9664.000  2312.000     0.000  7352.000       25  *Class#new
  6.27   2088.000  2088.000     0.000     0.000        9   Hash#merge
  4.08   1440.000  1360.000     0.000    80.000        5   Grape::Endpoint#run_filters

Switching to the simpler builder saves 7,60 Kbytes per request. Yeah, it isn't crazy number, but the change is one LOC. So, if you can agree with your team on using symbols everywhere, you can save a chunk of memory. By the way, the parameter builder can be configured per route, thus, the migration might be done per route.

However, if strings are used as keys for parameters:

  params do
    requires 'address', type: Hash do
      requires 'street', type: String
      requires 'postal_code', type: Integer
      optional 'city', type: String
    end
  end

  post '/' do
    declared = declared(params)
    declared['address']['street']
  end

the picture is a bit better for Grape::Extensions::ActiveSupport::HashWithIndifferentAccess::ParamBuilder.

Measure Mode: memory
Thread ID: 47413799950760
Fiber ID: 47413805177840
Total: 39832.000000
Sort by: self_time

 %self      total      self      wait     child     calls  name
 14.10   9064.000  5616.000     0.000  3448.000       18  *Hash#each_pair
 11.05  12448.000  4400.000     0.000  8048.000       29  *Class#new
  8.96   5088.000  3568.000     0.000  1520.000        8  *Array#map
  5.24   2088.000  2088.000     0.000     0.000        9   Hash#merge
  4.66   2016.000  1856.000     0.000   160.000        8   ActiveSupport::HashWithIndifferentAccess#[]=

Anyway Grape::Extensions::Hash::ParamBuilder is a winner.

Upcoming Grape 1.3.0

It has an improvement in Grape::Extensions::ActiveSupport::HashWithIndifferentAccess::ParamBuilder, so it will be slightly better.

Measure Mode: memory
Thread ID: 46918412761520
Fiber ID: 46918421185000
Total: 36448.000000
Sort by: self_time

 %self      total      self      wait     child     calls  name
 12.86   8336.000  4688.000     0.000  3648.000       11  *Hash#each_pair
  9.79   5248.000  3568.000     0.000  1680.000        8  *Array#map
  8.89  11880.000  3240.000     0.000  8640.000       27  *Class#new
  5.93   2160.000  2160.000     0.000     0.000       54   Symbol#to_s
  5.73   2088.000  2088.000     0.000     0.000        9   Hash#merge

Chrome: Cache storage VS Disk cache

Dmitriy Nesteryuk — Sat, 01 Jun 2019 15:07:18 +0000

Most likely, you've heard of Cache storage API and Service worker which might be used for caching resources and serving them later from the cache. One use case for that is prefetching resources before users need them.

I've been working on a project which implements the described use case. A few weeks ago, Stefan created a task where he described an observation that the speed of delivering assets from Cache storage is low in some cases. So, I decided to verify that.

I created demo to compare Cache storage and Disk cache. The index.html needs to display N images. There is an option to precache them then embed into the page. The sw.js looks into the cache, if resources are there, they get served from the cache, otherwise, they get normally downloaded.

Conditions of tests

Tests were only performed in Chrome. If there is enough interest, I might perform them in Firefox too. All images had identical size but different names to make the browser request them again and again. Below you will see the best results of 10 tries.

Chrome Dev tools provides timing for every resource.

Information about all loaded resources can be downloaded as a HAR file. Then any language/tool can be used to analyze the extracted information. In every try I was looking at time of loading all images. So, when you meet min, max or mean, I refer to the time when all images were loaded.

Test #1: 100 big images

For this test the image size was 1.5 Mb. In general, it is unlikely there are sites which load that many heavy images. It was more about curiosity.

Cache storage

Mostly, the browser spent time on downloading images. There is no clear pattern how the browser started to handle requests.

As I mentioned 10 tries were performed, so here is statistics about them:

min: 514.93 ms (represented in the above chart)
mean: 755.43 ms
max: 1031.07 ms

Disk cache

In this case, the download operation didn't take that much time, but images waited to be queued. We can even see how the browser took images for processing (approximately 6 images in one batch).

Statistics about 10 tries:

min: 646.73 ms (represented in the above chart)
mean: 1050.81 ms
max: 1450.36 ms

Cache storage is a clear winner in this test.

Test #2: 30 small images

For this test the image size was 31.3 Kb. This scenario has higher probability to be real than the previous one. I used images for tests, but it might be different assets (javascript files, fonts, images, css files etc), so some sites might load 30 assets on a page.

Cache storage

The download wasn't a problem any more but the waiting was.

Statistics about 10 tries:

min: 26.22 ms (represented in the above chart)
mean: 34.1 ms
max: 40.84 ms

Disk cache

Again, the queueing operation took more time than any other operation.

Statistics about 10 tries:

min: 15.3 ms (represented in the above chart)
mean: 22.89 ms
max: 28.97 ms

Now, Disk cache is a winner.

Test #3: 100 small images

Again, it is almost unreal case, but I was curios why Cache storage was faster in the first test. It might have been a number of images or the image size. So, I took the image from the previous test and loaded it 100 times.

Cache storage

Again, the waiting operation dominated here.

min: 65.5 ms (represented in the above chart)
mean: 78.54 ms
max: 90.51 ms

Disk cache

Again, the chart shows that the browser took the batch of 5-6 images and loaded them in parallel then took another batch.

min: 55.44 ms (represented in the above chart)
mean: 101.84 ms
max: 142.45 ms

By comparing the mean Cache storage is a winner again. So, I assume it is more about an ability to serve requests in parallel.

Wrap up

Even tests were performed on localhost results differ between tries. Disk cache was slightly better in delivering a small number of assets, Cache storage was better in delivering lots of assets. At some point, it is a little bit unfair to compare Cache storage and Disk cache, the first one has more wide use and developers have access to API to control it. Anyway, Cache storage isn't slow as it might have looked when the task was opened.