-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I think they're referring to the JIT compilation time. There are some ways to mitigate it, such as creating an image using PackageCompiler.jl, but it's definitely a noticeable issue IME. https://julialang.github.io/PackageCompiler.jl/dev/
The problem I seem with sysimages, is that the whole process is incredibly unergonomic for exploratory coding, which Julia always claims it is a primary use-case for. When you want to just glue some packages and quickly test out some results, the last thing you want to do is to think about what kinds of functions from libraries you are going to use beforehand, carefully write it in a precompilation file, and wait for the compiler to precompile and cache those code paths! And once those dependencies change even a bit you need to wait for precompilation again, which happens a lot when you're prototyping things fast or upgrading versions (for example, this X numerical computation library doesn't have a particular feature I want to use, so I want to switch to another library Y, but then you need to wait for everything to be precompiled again) The reality is that most people just want to fire up a virtualenv and "pip install " and don't want to get involved in any of this stuff. (As someone who uses C++ I have a lot more patience than other people, but you shouldn't really expect much from others)
I think Julia needs to throw away some of the unnecessary obsession for just-ahead-of-time (JAOT) compilation. Compiling everything beforehand to LLVM machine code seems good for raw runtime speed, but it doesn't matter when it takes so much setup time to even just glue some simple libraries. Julia should seriously consider running most of the less-computationally intensive codepaths in a custom-made interpreter without LLVM, while precompiling the numerically intensive parts of library code in raw machine code with the current LLVM backend. Maybe there should be a flag you can use to mark certain functions to be unconditionally compiled AOT-style, and leave the rest to the interpreter. Interpreters can be made surprisingly fast with some effort - stuff like LuaJIT (https://luajit.org/) and HashLink (https://hashlink.haxe.org/) is what comes into my mind.