[web2py] Re: web2py added on PyPy compatibility page
:-) On Jul 11, 9:13 am, Richard Vézina wrote: > ;-) > > Richard > > > > > > > > On Thu, Jul 7, 2011 at 5:31 PM, cjrh wrote: > > That is a complicated question: > > > 1) Single page load: no. This is generally an IO-bound kind of system, > > e.g. an infinitely fast processor would have almost no effect on response > > time. > > > 2) Concurrency/Scaling: generally, no. This is dominated by the DB > > backend, and (generally) the speed at which the DB can serve concurrent > > queries becomes limiting well before cPython gets too slow. > > > 3) Any code that gets "exec"ed by python: no. AFAIK PyPy doesn't do > > anything to exec() code, and that pretty much means your whole app. (I had a > > look---I can't find this mentioned anywhere, but I seem to have this idea > > stuck in my head from somewhere. Perhaps it was a limitation of an earlier > > PyPy version and no longer applies?) > > > What remains is the internal stuff, such as markmin, templating and other > > gluon/* code (and rocket!). So the final answer is a tentative "no", PyPy > > probably won't have too much impact on performance for web2py. So why > > bother? Because PyPy is the future of Python.
Re: [web2py] Re: web2py added on PyPy compatibility page
;-) Richard On Thu, Jul 7, 2011 at 5:31 PM, cjrh wrote: > That is a complicated question: > > 1) Single page load: no. This is generally an IO-bound kind of system, > e.g. an infinitely fast processor would have almost no effect on response > time. > > 2) Concurrency/Scaling: generally, no. This is dominated by the DB > backend, and (generally) the speed at which the DB can serve concurrent > queries becomes limiting well before cPython gets too slow. > > 3) Any code that gets "exec"ed by python: no. AFAIK PyPy doesn't do > anything to exec() code, and that pretty much means your whole app. (I had a > look---I can't find this mentioned anywhere, but I seem to have this idea > stuck in my head from somewhere. Perhaps it was a limitation of an earlier > PyPy version and no longer applies?) > > What remains is the internal stuff, such as markmin, templating and other > gluon/* code (and rocket!). So the final answer is a tentative "no", PyPy > probably won't have too much impact on performance for web2py. So why > bother? Because PyPy is the future of Python. >
Re: [web2py] Re: web2py added on PyPy compatibility page
That is a complicated question: 1) Single page load: no. This is generally an IO-bound kind of system, e.g. an infinitely fast processor would have almost no effect on response time. 2) Concurrency/Scaling: generally, no. This is dominated by the DB backend, and (generally) the speed at which the DB can serve concurrent queries becomes limiting well before cPython gets too slow. 3) Any code that gets "exec"ed by python: no. AFAIK PyPy doesn't do anything to exec() code, and that pretty much means your whole app. (I had a look---I can't find this mentioned anywhere, but I seem to have this idea stuck in my head from somewhere. Perhaps it was a limitation of an earlier PyPy version and no longer applies?) What remains is the internal stuff, such as markmin, templating and other gluon/* code (and rocket!). So the final answer is a tentative "no", PyPy probably won't have too much impact on performance for web2py. So why bother? Because PyPy is the future of Python.
Re: [web2py] Re: web2py added on PyPy compatibility page
Does it speed up web2py? Richard On Thu, Jul 7, 2011 at 11:28 AM, danto wrote: > 2011/7/7 cjrh > >> On Jul 7, 1:27 pm, cjrh wrote: >> > On further examination, it looks like leaking file descriptors is enough >> to >> > mark a library as "incompatible" (this happened with mercurial), so I >> have >> > changed web2py's to "incompatible" until we can fix all the leaks. >> >> I should also point out, to those not familiar with the background, is >> that the issue of file descriptors leaking is to some extent a PyPy >> issue, not a web2py issue! cPython automatically closes file handles >> when their references go out of scope, which means that in cPython it >> is safe to omit closing a file handle explicitly near the end of >> functions, or short functions, etc. cPython can do this because it >> uses a reference-counting approach to memory management, whereas PyPy >> implements a garbage collector, and requires (apparently) the file >> handle to be closed explicitly in order to collect the handle. This >> is one of the published incompatibilities between cPython and PyPy. >> >> So: there are no "leaks" in web2py running on cPython, this is purely >> a compatibility issue with PyPy. > > > Thank you very much for the info. > Kind regards. >
Re: [web2py] Re: web2py added on PyPy compatibility page
2011/7/7 cjrh > On Jul 7, 1:27 pm, cjrh wrote: > > On further examination, it looks like leaking file descriptors is enough > to > > mark a library as "incompatible" (this happened with mercurial), so I > have > > changed web2py's to "incompatible" until we can fix all the leaks. > > I should also point out, to those not familiar with the background, is > that the issue of file descriptors leaking is to some extent a PyPy > issue, not a web2py issue! cPython automatically closes file handles > when their references go out of scope, which means that in cPython it > is safe to omit closing a file handle explicitly near the end of > functions, or short functions, etc. cPython can do this because it > uses a reference-counting approach to memory management, whereas PyPy > implements a garbage collector, and requires (apparently) the file > handle to be closed explicitly in order to collect the handle. This > is one of the published incompatibilities between cPython and PyPy. > > So: there are no "leaks" in web2py running on cPython, this is purely > a compatibility issue with PyPy. Thank you very much for the info. Kind regards.
[web2py] Re: web2py added on PyPy compatibility page
On Jul 7, 1:27 pm, cjrh wrote: > On further examination, it looks like leaking file descriptors is enough to > mark a library as "incompatible" (this happened with mercurial), so I have > changed web2py's to "incompatible" until we can fix all the leaks. I should also point out, to those not familiar with the background, is that the issue of file descriptors leaking is to some extent a PyPy issue, not a web2py issue! cPython automatically closes file handles when their references go out of scope, which means that in cPython it is safe to omit closing a file handle explicitly near the end of functions, or short functions, etc. cPython can do this because it uses a reference-counting approach to memory management, whereas PyPy implements a garbage collector, and requires (apparently) the file handle to be closed explicitly in order to collect the handle. This is one of the published incompatibilities between cPython and PyPy. So: there are no "leaks" in web2py running on cPython, this is purely a compatibility issue with PyPy.
[web2py] Re: web2py added on PyPy compatibility page
On further examination, it looks like leaking file descriptors is enough to mark a library as "incompatible" (this happened with mercurial), so I have changed web2py's to "incompatible" until we can fix all the leaks.
