0

Question is self descriptive. If it can be controlled, how , i.e, what shell commands can I run in my *nix terminal ?

Why ? Because currently when I run with $ python3 *.py the first run of my long script with many imports is taking a few noticeable seconds to start whereas subsequent runs start instantly (presumably the JIT process happening behind the scenes; I hate behind the scenes).

I want to easily keep an eye on the fresh startup performance (subsequent runs could benefit from caching, especially of I/O) as that matters to me so I would like to manually get the byte-code JIT compilation of *.py to *.pyc part done in a separate step.

It's currently only one file, but please answer considering multiple files.

user426
  • 213
  • 2
  • 9
  • 1
    That's not "just in time" in the usual sense of the word. Real JIT compilation is generating host-native instructions, often from bytecode, and refining them after gathering performance metrics. CPython doesn't do that at all; it's just generating bytecode from source. – Charles Duffy Aug 01 '21 at 16:47
  • But yes, the Python runtime does let you explicitly parse (it's not really compilation) your .py files to .pyc – Charles Duffy Aug 01 '21 at 16:47
  • @CharlesDuffy I understand. But don't other JIT languages allow such control ? – user426 Aug 01 '21 at 16:48
  • @CharlesDuffy Oh, great. Would you consider posting an answer telling me how or comment linking resources ? – user426 Aug 01 '21 at 16:49
  • Linked an answer asking about pycompile for Python 3. Re: "other JIT languages" - take Java for example. When you run javac, that's not JIT -- JIT is what changes your bytecode in the .class files into x86/x64/arm/whatever instructions the CPU can actually run. javac is what changes your source code into bytecode, but that's ahead-of-time compilation, not JIT. – Charles Duffy Aug 01 '21 at 16:51
  • Thanks for closing the question, `py-compile` is the answer ! – user426 Aug 01 '21 at 16:52
  • 1
    The whole reason to do JIT in the first place is that it lets you use metrics measured at runtime to compile faster code than you could build if you couldn't look at what the program was actually doing (which branches it follows more frequently, etc) first. So by definition, it can't be done until after the program is running. – Charles Duffy Aug 01 '21 at 16:52
  • @CharlesDuffy may be off topic, and I dont know anything about JAVA, but heard that since recently android JIT compiles java apps upon install for fast startup – user426 Aug 01 '21 at 16:53
  • @CharlesDuffy " *The whole reason to do JIT in the first place is that it lets you use metrics measured at runtime to compile faster code* " but are JIT languages faster than compiled ? – user426 Aug 01 '21 at 16:54
  • 1
    Android for a long time has done link-time optimization at install time. And one can certainly do architecture-specific optimization to get something _ready_ for JIT-style optimization later. But to claim that one is doing true JIT at install time is... well, I'd want to see their defense of how the terminology applies. – Charles Duffy Aug 01 '21 at 16:55
  • "Are JIT languages faster than compiled?" -- err, it depends. Sometimes, after they've warmed up. A JIT runtime will _start off_ slower than a comparable ahead-of-time compiled program (assuming similarly competent compilers/runtimes), but it'll speed up as it runs. – Charles Duffy Aug 01 '21 at 16:55
  • @CharlesDuffy I am genuinely new to this. So should I conclude that JIT it better for long-running , branched code provided the sacrifices of initial slowness is acceptable ? – user426 Aug 01 '21 at 16:57
  • Often, yes, that's an accurate takeaway. – Charles Duffy Aug 01 '21 at 16:58
  • @CharlesDuffy Thanks for all the help ! – user426 Aug 01 '21 at 16:58

0 Answers0