Clear ORM
  • Welcome to Clear
  • Introduction
    • Setup
  • Model
    • Defining your model
      • Describing your columns
      • Primary Keys
      • Converters
    • Associations
      • belongs_to
      • has_many
      • has_many through
      • has_one
    • Lifecycle
      • Persistence
      • Validations
      • Triggers
    • Batchs operations
      • Bulk update
      • Bulk insert & delete
    • Transactions & Save Points
      • Transaction & Savepoints
      • Connection pool
    • Locks
  • Querying
    • The collection object
      • Filter the query
        • Filter the query – The Expression Engine
        • Find, First, Last, Offset, Limit
        • Aggregation
        • Ordering & Group by
      • Fetching the query
        • Each and Fetch
        • Cursored fetching
        • Model extra attributes
      • Joins
      • Eager Loading
      • Window and CTE
      • Scopes
    • Writing low-level SQL
      • Select Clause
      • Insert Clause
      • Delete Clause
  • Migrations
    • Manage migrations
    • Call migration script
    • Migration CLI
  • Additional and advanced features
    • JSONB
    • Symbol vs String
    • Enums
    • BCrypt
    • Full Text Search
    • Handling multi-connection
  • Other resources
    • API Documentation
    • Inline documentation
    • Github repository
    • Credits
    • Benchmark
Powered by GitBook
On this page
  • How fast is Clear?
  • Initial bootstrapping
  • Query and fetching benchmark
  • Against the competition
  1. Other resources

Benchmark

PreviousHandling multi-connection

Last updated 6 years ago

How fast is Clear?

Initial bootstrapping

Clear magic is built on compile time. Therefore, the impact on loading time is very limited. Clear can be used for example into web function (lambda function, google cloud function) application without any problem.

The only overhead is the connection to the database; Clear allocate by default 5 connections to PostgreSQL. In the case of mono-fiber web-function projects, you may want to reduce the connection pool to 1 only:

Clear::SQL.init("postgres://postgres@localhost/example_db", connection_pool_size: 1)

Another good performance improvement would be to connect through instead of directly to the database.

Query and fetching benchmark

Here is a simple benchmark comparing the different layers of Clear and how they impact the performance, over a 100k row very simple table:

With Model: With attributes and cursor    7.4  (135.09ms) (± 6.44%)  116409530 B/op   5.64× slower
               With Model: With cursor   8.61  (116.08ms) (± 2.82%)   97209247 B/op   4.84× slower
           With Model: With attributes  13.78  ( 72.59ms) (± 3.61%)   83101520 B/op   3.03× slower
          With Model: Simple load 100k  16.41  ( 60.94ms) (± 3.22%)   63901872 B/op   2.54× slower
                    Hash from SQL only  30.21  (  33.1ms) (± 5.18%)   22354496 B/op   1.38× slower
        Using: Model::Collection#pluck  41.74  ( 23.96ms) (± 8.35%)   25337128 B/op        fastest

Against the competition

Clear stands in the middle of the crowd, being slightly slower than some other ORM over select methods.

More noticeably, Clear performs 5 to 8x faster than Ruby's ActiveRecord !

While being a bit outdated, a benchmark of the competition .

PGBouncer
has been done here