This page contains benchmark results for some Prolog compilers. The main goal of this page it to give you some data for comparing predicate performance in plain Prolog and using Logtalk objects. Benchmark results are provided for both static code and dynamic code.

All the tests have been performed using the benchmarks example distributed with Logtalk version 2.30.4, with static binding enabled and event support disabled. This provides a best case scenario for comparing Logtalk performance with plain Prolog performance. The worst case scenario corresponds to only using dynamic binding with event support enabled. The benchmarks example contains loader files for easily setting up different test scenarios.

The benchmarks example provides a list length predicate (my_length/2) defined in plain Prolog and the same definition encapsulated in a Logtalk object (using the name length/2). The following goals are used for the benchmark tests:

s1: generate_list(20, List), my_length(List, _)

s2: generate_list(20, List), object::length(List, _)

When static binding is used, the performance of the two goals is expected to be similar. The performance of Logtalk can be slightly worse due to the overhead of the three extra arguments added to each compiled object predicate for carrying execution context information.

These benchmark tests use a list of 20 elements as an argument to the list length predicates. Increasing the list length may lead to decreasing performance differences between plain Prolog and Logtalk as the list length computation time starts to outweigh the overhead of the message sending mechanism. Likewise, decreasing the list length may lead to increasing performance differences between plain Prolog and Logtalk (up to the point you will be closing on the Logtalk message sending mechanism overhead when compared to plain Prolog predicate calls).

Category predicates can be called using either the ::/1 or the :/1 control constructs. When using the :/1 control construct, the lookup for both the predicate declaration and the predicate definition begins in this and is restricted to the imported categories. Depending on how the category is compiled, Logtalk may use static binding for :/1 calls, providing the same performance level as calls to local object predicates. The following goals are used for the benchmark tests:

c1: leaf::obj_local

c2: leaf::ctg_direct

c3: leaf::ctg_self

The obj_local method calls a local object predicate; the performance of such calls is equal or close to plain Prolog. The ctg_direct method uses the :/1 control construct to call an imported category predicate. The ctg_self method uses the ::/1 message sending control construct to call an imported category predicate. While the :/1 calls may use static binding, the ::/1 calls always use dynamic binding and a lookup caching mechanism. Note that the choice between either control construct is not simply a question of performance as the control constructs provide different semantics for calling imported category predicates. All three predicates perform the same computation (generating a list of twenty elements and calculating its length) using local predicates.

Dynamic code tests include both object database updates and creating and abolishing dynamic objects. The benchmarks example provides a an object named database, which defines a set of predicates for testing the Logtalk built-in database methods as described below. The following goals are used for the benchmark tests:

d1: create_object(xpto, [], [], []), abolish_object(xpto)

d2: plain_dyndb(_)

d3: database::this_dyndb(_)

d4: database::self_dyndb(_)

d5: database::obj_dyndb(_)

The first test simply creates and abolishes a (dynamic) object. The remaining tests are used for benchmarking object database updates, comparing with plain Prolog database updates. The *_dyndb tests simply assert (using assertz/1) and retract a clause (using retract/1) of a dynamic predicate with arity one. The plain_dyndb(_) test uses the Prolog built-in database predicates. The other three tests use the Logtalk built-in database methods, using a direct method call (this_dyndb(_)), a call using ::/1 (self_dyndb(_)), and a call using ::/2 (obj_dyndb(_)).

All results are given in number of calls per second. By default, the benchmark code repeats each goal 100000 times in order to get more accurate results.

All results are given in number of calls per second. By default, the benchmark code repeats each goal 100000 times in order to get more accurate results.

All results are given in number of calls per second. By default, the benchmark code repeats each goal 100000 times in order to get more accurate results.

• All benchmark tests use the default memory allocation for the different program areas. Changing the size of these program areas can have a big impact on the benchmark results (e.g. increasing stack size to avoid wasting time expanding the stack or doing garbage collection).
• These are to few and to limited benchmark tests to effectively compare Prolog compiler performance.
• Processor caches sometimes result in tests one order of magnitude better than the results posted above.
• Some of the Prolog built-in predicates used for measuring CPU time are not as accurate as we would like. Despite each benchmark goal being proved by default 100000 times, repeating the tests always show some variation on the final results.
• The more real work your object and category predicates do, the less significant the Logtalk message sending overheads become.
• In real-life applications, only testing can give you a balanced view on the trade-offs between plain Prolog performance and Logtalk programming features.