On Thu, Jan 21, 2010 at 3:00 PM, Steve Steiner (listsin)
<list...@integrateddevcorp.com> wrote:
>
> 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.
>

Unfortunately that model doesn't work particularly well with a JIT.
The point of a JIT is that it can respond to runtime feedback, and
take advantage of run time data.  If you were to precompile it you'd
lose interpretter overhead, and nothing else, because you can't do
things like embed pointers to data in the assembly.

Alex

P.S.: SOrry to anyone who I personally sent that message to, stupid
reply to all not being the default...

> 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/alex.gaynor%40gmail.com
>



-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
_______________________________________________
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