> What makes you think people will even read this warning, let alone > prioritize it over their immediate desire to make their program run > faster?
> (Not that I am objecting to adding the warning, but I think you might be > fooling yourself if you think it will have any impact) > Jean-Paul I agree with you and was not being naive and thinking this alone was going to solve the problem but it does gives us something to point to when we see someone abusing the jitviewer. Maybe, a more effective approach, is not to advertise about the jitviewer to everyone who has performance issues and only tell those who are experience programmers who have already done the obvious in fixing any design issues that had existed in their code. Having inexperience developers use the normal profiling tools will still help them find the hot spots in their code and help prevent them from picking up habits that lead them to writing un-Pythonic code. I'm sure we all agree that code with a better design will run faster in pypy than trying to add optimizations that work only for pypy to help out a poor design. I don't think we want to end up with a lot of Python code that looks like C code. This is what happens when the inexperience start relying on the jitviewer. For instance take a look at this code [1] and blog [2] which lead me to post this. This is not the first example I have come across this issue and unfortunately it appears to be increaseing at an alarming rate. I guess I feel we have a responsibility to try to promote good programming practices when we can. [1] - https://github.com/msgpack/msgpack-python/blob/master/msgpack/fallback.py [2] - http://blog.affien.com/archives/2013/01/29/msgpack-for-pypy/ John On Sun, Feb 3, 2013 at 12:39 PM, John Camara <john.m.cam...@gmail.com>wrote: > I have been noticing a pattern where many who are writing Python code to > run on PyPy are relying more and more on using the jitviewer to help them > write faster code. Unfortunately, many of them who do so don't look at > improving the design of their code as a way to improve the speed at which > it will run under PyPy but instead start writing obscure Python code that > happens to run faster under PyPy. > > I know that at least with the PyPy core developers they would like to see > every one just create good clean Python code and that often code that has > been made into obscure Python was don so to try to optimize it for CPython > which in many cases causes it to run slower on PyPy than it would run it > the code just followed typical Python idioms. > > I feel that a normal developer should be using tools like cProfiler and > runsnakerun and cleaning up design issues way before they should even > consider using jitviewer. > > In a recent case where I saw someone using the jitviewer who likely > doesn't need to use it. At least they don't need to use it considering the > current design of the code I said the following > > "The jitviewer should be mainly used by PyPy core developers and those > building PyPy VMs. A normal developer writing Python code to run on PyPy > shouldn’t have a need to use it. They can use it to point out an > inefficiency that PyPy has to the core developers but it should not be used > as a way to get you to write Python code in a way that has a better chance > of being optimized under PyPy except for very rare occasions and even then > it should only be made by those who follow closely and understand PyPy’s > development." > > > Do others here share this same opinion and should some warning be added to > the jitviewer? > > John >
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
