Awesome

Ply File I/O Benchmark

This repository contains code for comparison of various libraries for input and output of PLY files. PLY file format has been developed at Stanford University by Greg Turk as a part of the real-world object digitization project undertaken by Stanford University in mid-90s.

Task

The task is to read and write a basic triangle mesh stored in a PLY. The triangle mesh is represented as a list of vertices and a list of triangles, indicating which triplets of vertices make a triangle.

The data structure we wish to populate is:

typedef struct vec3f
{
  float x,y,z;
} Vec3f;

typedef struct tri
{
  int index1, index2, index3;
} Tri;

typedef struct triangle_mesh
{
  int n_verts;
  int n_faces;
  Vec3f* vertices;
  Tri* faces;
} TriMesh;

The meshes we are testing were processed to contain only the position attribute and only triangle faces. As such this task aims to measure the speed at which each library is able to exchange simple triangular mesh data. Each of the meshes is tested using both binary and text(ASCII) formats, as supported by PLY file format. For binary we use little-endian.

Mesh size vs. number of meshes

This benchmark focuses on rather large meshes (15k - 28 million triangles). The use case this benchmark analyzes is to minimize the time taken to load such large meshes. If your task is to read a lot of smaller .ply files, then this benchmark might not be reflective of your situation.

For an alternative task, where a large number of smaller meshes is parsed, and where meshes might have more varied per-vertex attribute list, please see the excellent ply-parsing-perf benchmark by Vilya Harvey.

Known list size

Given that in our task we process only triangular meshes, it would be good to let the application know this information. Some libraries (see below) allow passing the expected size of list properties, leading to non-negligible speed-up in parsing. As such, where applicable, this feature has been enabled.

Test Models

The table below lists models used for this benchmark, along with the source.

Libraries

Below is a list of libraries used in this benchmark:

For the usage examples, as well as some additional comments about each of the libraries please check the tests/*_test.c(pp) files.

Results

Below we present results for parsing PLY files storing data in both ASCII and binary format (little-endian). Times are given in milliseconds. Highlighted numbers indicate the best method in each category. As noted before, where applicable, a known list size is passed to the library.

The benchmark was compiled using MSVC 19.28.29334 with \O2 optimization flag, using AMD Ryzen 3900XT and Samsung 970 EVO PLUS.

To run the test, we run a separate program for each file that attempts to read and write the input file, and reports time taken to do so. Program for each library is run 10 times and the results are averaged. The averaged time taken for each model is used to compute the overall average time it took to process all the models.

• Disclaimer: I am the author of msh_ply library. If you see any deficiencies in code for other libraries, don't hesitate to let me know - I hope to make this benchmark as fair as possible. *

Average Read Times

Average Write Times

Notes:

• miniply is the fastest library for reading the ply files. If you're only interested in reading files and use C++, it is a great choice.
• miniply and micro_ply do not support the writing of ply files.
• micro_ply does not support binary files, only ASCII format.
• In C, when you need decent read and write performance, msh_ply is a good choice ;). However, it's ASCII mode requires work, so if your models are mostly stored in ASCII, you might want to use other libraries.
• Some libraries were modified to include getter to establish whether input is binary or ASCII.
• In ASCII mode, happly is unable to convert between uint and int. Since some models (angel, bust_of_sappho, bust_of_angelique_dhannetaire ) contain vertex list specified as uint, while others use int, happly fails to parse the two aforementioned models and would need to be recompiled to support the specific type. Here, we simply omit these models when benchmarking happly.

Per model I/O times:

Note that the images show the read time on a log scale, since the performance of different libraries is significantly different.

LOC

Another metric we can use for deciding a library is the ease of use. Why LOC is by no means a perfect metric to measure ease of use, it does reflect how much code one needs to type to get basic PLY I/O done. Also, note that these numbers report only simple versions of reading function without any error reporting, etc.