mongo_orm VS are-we-fast-yet

Compare mongo_orm vs are-we-fast-yet and see what are their differences.

mongo_orm

Mongo ORM: A simple ORM for using MongoDB with the crystal programming language, designed for use with Amber. Based loosely on Granite ORM. Supports Rails-esque models, associations and embedded documents. (by sam0x17)

are-we-fast-yet

Are We Fast Yet? Comparing Language Implementations with Objects, Closures, and Arrays (by smarr)
Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
mongo_orm are-we-fast-yet
1 18
32 315
- -
0.0 8.8
almost 4 years ago about 1 month ago
Crystal Java
MIT License GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

mongo_orm

Posts with mentions or reviews of mongo_orm. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2020-12-24.

are-we-fast-yet

Posts with mentions or reviews of are-we-fast-yet. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-01-21.
  • Boehm Garbage Collector
    9 projects | news.ycombinator.com | 21 Jan 2024
    > Sure there's a small overhead to smart pointers

    Not so small, and it has the potential to significantly speed down an application when not used wisely. Here are e.g. some measurements where the programmer used C++11 and did everything with smart pointers: https://github.com/smarr/are-we-fast-yet/issues/80#issuecomm.... There was a speed down between factor 2 and 10 compared with the C++98 implementation. Also remember that smart pointers create memory leaks when used with circular references, and there is an additional memory allocation involved with each smart pointer.

    > Garbage collection has an overhead too of course

    The Boehm GC is surprisingly efficient. See e.g. these measurements: https://github.com/rochus-keller/Oberon/blob/master/testcase.... The same benchmark suite as above is compared with different versions of Mono (using the generational GC) and the C code (using Boehm GC) generated with my Oberon compiler. The latter only is 20% slower than the native C++98 version, and still twice as fast as Mono 5.

  • A C++ version of the Are-we-fast-yet benchmark suite
    2 projects | /r/cpp | 26 Jun 2023
    See https://github.com/smarr/are-we-fast-yet/blob/master/docs/guidelines.md.
  • Are We Fast Yet? Comparing Language Implementations with Objects, Closures, and Arrays
    2 projects | /r/programming | 20 Mar 2022
  • .NET 6 vs. .NET 5: up to 40% speedup
    15 projects | news.ycombinator.com | 21 Nov 2021
    > Software benchmarks are super subjective.

    No, they are not, but they are just a measurement tool, not a source of absolute thruth. When I studied engineering at ETH we learned "Who measures measures rubbish!" ("Wer misst misst Mist!" in German). Every measurement has errors and being aware of these errors and coping with it is part of the engineering profession. The problem with programming language benchmarks is often that the goal is to win by all means; to compare as fairly and objectively as possible instead, there must be a set of suitable rules adhered to by all benchmark implementations. Such a set of rules is e.g. given for the Are-we-fast-yet suite (https://github.com/smarr/are-we-fast-yet).

  • Is CoreCLR that much faster than Mono?
    2 projects | news.ycombinator.com | 29 Aug 2021
    I am aware of the various published test results where CoreCLR shows fantastic speed-ups compared to Mono, e.g. when calculating MD5 or SHA hash sums.

    But my measurements based on the Are-we-fast-yet benchmark suite (see https://github.com/smarr/are-we-fast-yet and https://github.com/rochus-keller/Oberon/tree/master/testcases/Are-we-fast-yet) show a completely different picture. Here the difference between Mono and CoreCLR (both versions 3 and 5) is within +/- 10%, so nothing earth shattering.

    Here are my measurement results:

    https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf comparing the same benchmark on the same machine run under LuaJIT, Mono, Node.js and Crystal.

    https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_windows.pdf comparing Mono, .Net 4 and CoreCLR 3 and 5 on the same machine.

    Here are the assemblies of the Are-we-fast-yet benchmark suite used for the measurements, in case you want to reproduce my results: http://software.rochus-keller.ch/Are-we-fast-yet_CLI_2021-08-28.zip.

    I was very surprised by the results. Perhaps it has to do with the fact that I measured on x86, or that the benchmark suite used includes somewhat larger (i.e. more representative) applications than just micro benchmarks.

    What are your opinions? Do others have similar results?

  • Is CoreCLR really that much faster than Mono?
    6 projects | /r/dotnet | 29 Aug 2021
    But my measurements based on the Are-we-fast-yet benchmark suite (see https://github.com/smarr/are-we-fast-yet and https://github.com/rochus-keller/Oberon/tree/master/testcases/Are-we-fast-yet) show a completely different picture. Here the difference between Mono and CoreCLR (both versions 3 and 5) is within +/- 10%, so nothing earth shattering.
    6 projects | /r/dotnet | 29 Aug 2021
    There is a good reason for this; have a look at e.g. https://github.com/smarr/are-we-fast-yet/blob/master/docs/guidelines.md.
  • Ranking programming languages by energy efficiency (scientific paper, 2021)
    5 projects | /r/ProgrammingLanguages | 7 Feb 2021
    If you want to compare different language implementations, you have to somehow control what you compare; the implementations must do the same thing with the same quantity, and especially for VMs and interpreters you want to make sure that you're not comparing a native library call with an interpreted version of the same function. The Are-we-fast-yet has a decent set of rules from by point of view to enable fair comparisons, and even though it's still possible to use ideomatic paradigms supported by the language. Have you seen this document: https://github.com/smarr/are-we-fast-yet/blob/master/docs/guidelines.md?
    5 projects | /r/ProgrammingLanguages | 7 Feb 2021
    Personally, I like this benchmark suite better, but unfortunately the number of implementations is still quite small: https://github.com/smarr/are-we-fast-yet
    5 projects | /r/ProgrammingLanguages | 7 Feb 2021
    See the publication (https://stefan-marr.de/papers/dls-marr-et-al-cross-language-compiler-benchmarking-are-we-fast-yet/) about what rules they apply. The code is ideomatic, but they require that all implementations use the same data structure implementations to make it comparable. Here is a discussion in the pull request: https://github.com/smarr/are-we-fast-yet/pull/30.

What are some alternatives?

When comparing mongo_orm and are-we-fast-yet you can also consider the following projects:

gleam - ⭐️ A friendly language for building type-safe, scalable systems!

crystal - The Crystal Programming Language

fast-ruby - :dash: Writing Fast Ruby :heart_eyes: -- Collect Common Ruby idioms.

PyCall.jl - Package to call Python functions from the Julia language

Oberon - Oberon parser, code model & browser, compiler and IDE with debugger

mosquito - Trading Bot with focus on Evolutionary Algorithms and Machine Learning

.NET Runtime - .NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.

normandy - Channels for CSP style Ruby

gcf.cr - gcf.cr provides serverless execution and deployment of crystal language code in Google Cloud Functions

Smalltalk - Parser, code model, interpreter and navigable browser for the original Xerox Smalltalk-80 v2 sources and virtual image file