Benchmarks

The following tables show benchmarks that compare Ripserer's performance with Ripser and Cubical Ripser. The benchmarking code and more info about the datasets is available here.

All benchmarks were performed on a laptop with an Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz with 8GB of RAM.

We used BenchmarkTools.jl to perform the timing benchmarks and Valgrind's Massif tool to measure peak heap sizes (i.e. total memory footprint).

All benchmarks include I/O, so there might be some noise in the smaller benchmarks. For Ripserer, CSV.jl was used to read the files. Ripserer's memory footprint benchmarks include the Julia runtime, which tends to use around 100MiB memory.

The benchmarks were performed with Ripserer v0.14.3 and master versions of Ripser (commit hash 286d369) and Cubical Ripser (commit hashes 6edb9c5 for 2D and a063dac for 3D).

Vietoris-Rips Persistent Homology

In this experiment, we performed benchmarks with the datasets presented in the Ripser article. We only used the datasets that we were able to run with less than 8GB memory. ripserer_s denotes ripserer run with SparseRips. All datasets were parsed as Float32 as that is what Ripser supports.

The timing results are in the table below. The ratio column shows the better ratio.

The next table shows peak heap sizes as reported by valgrind.

Alpha-Rips Persistent Homology

Here, we used the 1-skeleton of the Delaunay triangulation of a point cloud as a sparse distance matrix. This benchmark is intended to benchmark performance in very sparse cases, as triangulations only have $\mathcal{O}(n)$ $d$-simplices. All datasets were parsed as Float32 as that is what Ripser supports.

Timing results:

Peak heap size:

Cubical Persistent Homology

In this benchmark, we use some of the datasets presented in the Cubical Ripser article. We limited the 2D image size to 1999×999 as the current master (commit hash 6edb9c5) version of 2D Cubical Ripser throws an assertion error for anything larger. We were also unable to perform 3D 256×256×256 image benchmarks due to Ripserer running out of memory. The eltype of all datasets is Float64, because that is what Cubical Ripser supports. When running Ripserer in the real world, it's a good idea to use the native data types. This will slightly reduce the memory footprint and increase performance.

Timing results:

Peak heap size: