PackageCompiler.jl
line_profiler
PackageCompiler.jl | line_profiler | |
---|---|---|
26 | 17 | |
1,371 | 2,488 | |
0.5% | 1.3% | |
7.8 | 8.5 | |
8 days ago | 2 days ago | |
Julia | Python | |
MIT License | GNU General Public License v3.0 or later |
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.
PackageCompiler.jl
-
Potential of the Julia programming language for high energy physics computing
Yes, julia can be called from other languages rather easily, Julia functions can be exposed and called with a C-like ABI [1], and then there's also various packages for languages like Python [2] or R [3] to call Julia code.
With PackageCompiler.jl [4] you can even make AOT compiled standalone binaries, though these are rather large. They've shrunk a fair amount in recent releases, but they're still a lot of low hanging fruit to make the compiled binaries smaller, and some manual work you can do like removing LLVM and filtering stdlibs when they're not needed.
Work is also happening on a more stable / mature system that acts like StaticCompiler.jl [5] except provided by the base language and people who are more experienced in the compiler (i.e. not a janky prototype)
[1] https://docs.julialang.org/en/v1/manual/embedding/
[2] https://pypi.org/project/juliacall/
[3] https://www.rdocumentation.org/packages/JuliaCall/
[4] https://github.com/JuliaLang/PackageCompiler.jl
[5] https://github.com/tshort/StaticCompiler.jl
- Strong arrows: a new approach to gradual typing
-
Making Python 100x faster with less than 100 lines of Rust
One of Julia's Achilles heels is standalone, ahead-of-time compilation. Technically this is already possible [1], [2], but there are quite a few limitations when doing this (e.g. "Hello world" is 150 MB [7]) and it's not an easy or natural process.
The immature AoT capabilities are a huge pain to deal with when writing large code packages or even when trying to make command line applications. Things have to be recompiled each time the Julia runtime is shut down. The current strategy in the community to get around this seems to be "keep the REPL alive as long as possible" [3][4][5][6], but this isn't a viable option for all use cases.
Until Julia has better AoT compilation support, it's going to be very difficult to develop large scale programs with it. Version 1.9 has better support for caching compiled code, but I really wish there were better options for AoT compiling small, static, standalone executables and libraries.
[1]: https://julialang.github.io/PackageCompiler.jl/dev/
-
What's Julia's biggest weakness?
Doesn’t work on Windows, but https://github.com/JuliaLang/PackageCompiler.jl does.
-
I learned 7 programming languages so you don't have to
Also, you can precompile a whole package and just ship the binary. We do this all of the time.
https://github.com/JuliaLang/PackageCompiler.jl
And getting things precompiled: https://sciml.ai/news/2022/09/21/compile_time/
-
Julia performance, startup.jl, and sysimages
You can have a look at PackageCompiler.jl
-
Why Julia 2.0 isn’t coming anytime soon (and why that is a good thing)
I think by PackageManager here you mean package compiler, and yes these improvements do not need a 2.0. v1.8 included a few things to in the near future allow for building binaries without big dependencies like LLVM, and finishing this work is indeed slated for the v1.x releases. Saying "we are not doing a 2.0" is precisely saying that this is more important than things which change the user-facing language semantics.
And TTFP does need to be addressed. It's a current shortcoming of the compiler that native and LLVM code is not cached during the precompilation stages. If such code is able to precompile into binaries, then startup time would be dramatically decreased because then a lot of package code would no longer have to JIT compile. Tim Holy and Valentin Churavy gave a nice talk at JuliaCon 2022 about the current progress of making this work: https://www.youtube.com/watch?v=GnsONc9DYg0 .
This is all tied up with startup time and are all in some sense the same issue. Currently, the only way to get LLVM code cached, and thus startup time essentially eliminated, is to build it into what's called the "system image". That system image is the binary that package compiler builds (https://github.com/JuliaLang/PackageCompiler.jl). Julia then ships with a default system image that includes the standard library in order to remove the major chunk of code that "most" libraries share, which is why all of Julia Base works without JIT lag. However, that means everyone wants to have their thing, be it sparse matrices to statistics, in the standard library so that it gets the JIT-lag free build by default. This means the system image is huge, which is why PackageCompiler, which is simply a system for building binaries by appending package code to the system image, builds big binaries. What needs to happen is for packages to be able to precompile in a way that then caches LLVM and native code. Then there's no major compile time advantage to being in the system image, which will allow things to be pulled out of the system image to have a leaner Julia Base build without major drawbacks, which would then help make the system compile. That will then make it so that an LLVM and BLAS build does not have to be in every binary (which is what takes up most of the space and RAM), which would then allow Julia to much more comfortably move beyond the niche of scientific computing.
- Is it possible to create a Python package with Julia and publish it on PyPi?
- GenieFramework – Web Development with Julia
-
Julia for health physics/radiation detection
You're probably dancing around the edges of what [PackageCompiler.jl](https://github.com/JuliaLang/PackageCompiler.jl) is capable of targeting. There are a few new capabilities coming online, namely [separating codegen from runtime](https://github.com/JuliaLang/julia/pull/41936) and [compiling small static binaries](https://github.com/tshort/StaticCompiler.jl), but you're likely to hit some snags on the bleeding edge.
line_profiler
- Ask HN: C/C++ developer wanting to learn efficient Python
- New version of line_profiler: 4.1.0
-
Making Python 100x faster with less than 100 lines of Rust
LineProfiler is the best tool to learn how to write performant Python and code optimization.
https://github.com/pyutils/line_profiler
You can literally see the hot spot of your code, then you can grind different algorithms or change the whole architecture to make it faster.
For example replace short for loops to list comprehensions, vectorize all numpy operations (only vectorize partially do not help the issue), using 'not any()' instead or 'all()' for boolean, etc.
Doing this for like 2 weeks, basically you can automatically recognized most bad code patterns in a glance.
-
Why is my Pubmed plant search app so slow?
You may want to try using a package like line_profiler to narrow down where the time is spent.
-
How to make nested for loops run faster
When tuning for performance, always measure. Never assume you know where the slow parts are. Run a line profiler and see where all the time is actually going.
-
I'm working on a world map generator, but I have one function in particular that is very slow and keeping me from being able to scale my maps to as large as I'd like... is there a way that I can optimize this depth first search function, or another way of grouping contiguous cells based on criteria?
Either way I would highly recommend running a profiler on your code to see where the program is spending most of its time. line_profiler is a very nice one, as it shows you execution time for each line.
-
Is it possible to make a function to check how many lines of code have been executed in the program so far (including said function’s lines)?
There are dedicated tools like line_profiler for python - if this doesn't do exactly what you need it can be easily modified.
-
Why does sklearn.Pipeline with regex outperform spacy for text preprocessing?
It's surprising to me that an sklearn pipeline and a spacy pipeline both doing simple regexing are vastly different in performance. I would go one layer deeper with measurement with something like line_profiler, which I've used to great effect to get line-by-line perf stats. This should illuminate why.
-
Hot profiling for Python
This looks really nice! Does it use line_profiler or is it a different implementation for the profiling? Either way the interface is fantastic!
-
Profiling and Analyzing Performance of Python Programs
# https://github.com/pyutils/line_profiler pip install line_profiler kernprof -l -v some-code.py # This might take a while... Wrote profile results to some-code.py.lprof Timer unit: 1e-06 s Total time: 13.0418 s File: some-code.py Function: exp at line 3 Line # Hits Time Per Hit % Time Line Contents ============================================================== 3 @profile 4 def exp(x): 5 1 4.0 4.0 0.0 getcontext().prec += 2 6 1 0.0 0.0 0.0 i, lasts, s, fact, num = 0, 0, 1, 1, 1 7 5818 4017.0 0.7 0.0 while s != lasts: 8 5817 1569.0 0.3 0.0 lasts = s 9 5817 1837.0 0.3 0.0 i += 1 10 5817 6902.0 1.2 0.1 fact *= i 11 5817 2604.0 0.4 0.0 num *= x 12 5817 13024902.0 2239.1 99.9 s += num / fact 13 1 5.0 5.0 0.0 getcontext().prec -= 2 14 1 2.0 2.0 0.0 return +s
What are some alternatives?
StaticCompiler.jl - Compiles Julia code to a standalone library (experimental)
SnakeViz - An in-browser Python profile viewer
julia - The Julia Programming Language
memory_profiler - Monitor Memory usage of Python code
Genie.jl - 🧞The highly productive Julia web framework
reloadium - Hot Reloading and Profiling for Python
LuaJIT - Mirror of the LuaJIT git repository
pprofile - Line-granularity, thread-aware deterministic and statistic pure-python profiler
Dash.jl - Dash for Julia - A Julia interface to the Dash ecosystem for creating analytic web applications in Julia. No JavaScript required.
psutil - Cross-platform lib for process and system monitoring in Python
Transformers.jl - Julia Implementation of Transformer models
prometeo - An experimental Python-to-C transpiler and domain specific language for embedded high-performance computing