On Jan 21, 2010, at 3:20 PM, Collin Winter wrote:

> Hey Greg,
> 
> On Wed, Jan 20, 2010 at 10:54 PM, Gregory P. Smith <g...@krypto.org> wrote:
>> +1
>> My biggest concern is memory usage but it sounds like addressing that is
>> already in your mind.  I don't so much mind an additional up front constant
>> and per-line-of-code hit for instrumentation but leaks are unacceptable.
>>  Any instrumentation data or jit caches should be managed (and tunable at
>> run time when possible and it makes sense).
> 
> Reducing memory usage is a high priority. One thing being worked on
> right now is to avoid collecting runtime data for functions that will
> never be considered hot. That's one "leak" in the current
> implementation.

Me, personally, I'd rather that you  give me the profile information to make my 
own decisions, give me an @hot decorator to flag things that I want to be sped 
up, and let me switch the heat profiling  gymnastics out of the runtime when I 
don't want them.

That way, I can run a profile if I want to get the info to flag the things that 
are important, but a normal run doesn't waste a lot of time or energy doing 
something I don't want it to do during a "regular" run.

Ideally, I could pre-JIT as much as possible on compile so that I could 
"precompile" my whole app pay the minimum JIT god's penalty at runtime.

Yes, sometimes I'd like to run on "full automatic", but not often.  I run a 
*lot* of quick little scripts that do a few intense things once or in a tight 
loop.  I know where the hotspots are, and I want them compiled before they're 
*ever* run.  

99% of the time, I don't need a runtime babysitter, I need a performance boost 
in known places, right away and without any load or runtime penalty to go along 
with it.

S

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to