Question

I am using a high performance/parallel graph library written in C in a C++ project. It provides a struct stinger (the graph data structure) and operations like

int stinger_insert_edge_pair (struct stinger *G,
                          int64_t type, int64_t from, int64_t to,
                          double weight, int64_t timestamp) { .... }

Most of the time, however, I do not want to specify timestamps or weights or types. Default parameters would be nice. Also, an OOP-like interface would be nice: G->insertEdge(u, v) instead of insert_edge_pair(G, u, v, ...).

So I was thinking of creating an adapter class looking like

class Graph {

protected:

    stinger* stingerG;

public:

    /** default parameters ***/

    double defaultEdgeWeight = 1.0;


    /** methods **/

    Graph(stinger* stingerG);

     virtual void insertEdge(node u, node v, double weight=defaultEdgeWeight);

   };

The method insertEdge(...) simply calls stinger_insert_edge_pair(this->stingerG, ...) with the appropriate parameters.

However, performance is a crucial aspect here. What is the performance penalty associated with using such an adapter class? Should I expect degraded performance compared to using the “naked” library?

Answer 1

If your insertEgde just forwards the call to stinger_insert_edge_pair there would (most probably) be no difference in code generated between the plain call to stinger_insert_edge_pair and g->insertEdge (provided you remove the virtual specifier).
Comparing the assembly code that is generated through the plain call and adapter call would give a fair input on the overhead your adapter is bring in.

Does insertEdge have to be virtual? Are you planning to have subclasses of Graph? But again, cost of virtual function call is almost negligible compared to real cost the function execution itself.