I made a video about reducing Julia’s latency after a conversation with a friend who said that they really wish all of this information was in one place.
Hence, you get this video. Possibly part one of two, where in the second I cover the packages I referenced in the outro of this one (JuliaFormatter, JET, Aqua, and Cthulhu).
Feedback is very welcome! I will mention, though, that while I do talk about some advanced topics, I try to not go into too much detail so if I glossed over some parts of the video or didn’t mention stuff (how PackageCompiler can do so much more or that the part that I discussed will hopefully one day be redundant) it might be because I decided not to put it in.
Thanks for watching and filling out my workflow survey if you did
Very cool tutorial, taught me a few things, and I loved the drawings
A minor caveat was that the code was changing way too fast (and maybe in too small a font) for me to follow. Perhaps something to keep in mind for the next video?
I also agree that these tips and tricks should stop being part of an unspoken lore and start being explicitly documented in one place. I would love to draft a blog post for the Julia blog, something like “Modern Julian workflows”, where I give an annotated list of what it takes to easily use, and then develop, packages. If you and my idol @jakobnissen would like to contribute, we could get this going.
He was one of the two channels whose style I wanted to emulate along with code_report. Tris got me into Rust, Conor got me into array languages, I hope I can get someone into Julia
Creating new packages, and utilizing Revise.jl the way you showed us, is pretty much contradicting the purpose of a REPL to me.
A REPL is meant to give me straight access to a development environment, and not something that needs complicated setup, that the vast majority of newbies will not even consider to use.
I certainly wouldn’t, and you outline one of the core issues with our REPL workflow. But the proposed solution is even worse to me, than just having to wait half an eternity for the REPL to come up, and then me having to think to close it, if there are still old functions stored.
It complicates things just further, in my opinion.
And we do have an interpreter, that I would like to use as the default backend for the REPL.
No huge startup, and more suitable for small code.
I just think adding @interpret for every execution can be skipped, and loading it in manually seems also counterintuitive to new users.
Is there a huge benefit to JIT all the code at the standard REPL instead?
The interpreter is painful slow for anything more than trivial code. The Debugger is run by the Interpreter, and you don’t have to search very far to find someone be bemoaning the Debugger’s speed. This is why the Debugger has partial compiled mode where most modules are compiled and only user code is interpretered.
Tim Holy has mentioned elsewhere (sorry don’t have a link on hand) that the interpreter could benefit from running the Julia level optimizations before running (cut out the LLVM comp time), but it hasn’t been a higher priority than getting precompilation and such. The introduction of JuliaSyntax should make it easier to trace the optimized Julia IR back to source code, so adding this should be possible now
