ctypes create_string_buffer
import ctypes as C s1= "0"* 1024* 1024* 10 # mem engross add 10M bytes b1= C.create_string_buffer(s1 ) # CPU 1 core 100% and mem engross add 300M bytes ? I don't know! please talk me, thanks very match.... I'm chinese, english is not good, sorry!
ctypes is not nice to use. If you need C-bindings, please look at CFFI. Sent from my iPhone
On 09/01/2014, at 14.30, HY <lightdarkadmin@163.com> wrote:
import ctypes as C s1= "0"* 1024* 1024* 10 # mem engross add 10M bytes b1= C.create_string_buffer(s1 ) # CPU 1 core 100% and mem engross add 300M bytes ? I don't know! please talk me, thanks very match....
I'm chinese, english is not good, sorry!
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
Hi, On Fri, Jan 10, 2014 at 2:52 PM, Kenny Lasse Hoff Levinsen <kennylevinsen@gmail.com> wrote:
On 09/01/2014, at 14.30, HY <lightdarkadmin@163.com> wrote: import ctypes as C s1= "0"* 1024* 1024* 10 # mem engross add 10M bytes b1= C.create_string_buffer(s1 ) # CPU 1 core 100% and mem engross add 300M bytes ? I don't know! please talk me, thanks very match....
Fixed, thanks! It might have been a long-standing issue with memory in ctypes: memory was not promptly released, leading to the apparence of leaks.
ctypes is not nice to use. If you need C-bindings, please look at CFFI.
It's true that we usually recommend to look at CFFI instead of using ctypes, but we still look at and fix the most obvious performance problems with ctypes. The goal for us is to avoid having it run horribly more slowly than on CPython. A bientôt, Armin.
I test 2f0d7dced731 memory isn't large engross. but at the AMD 5000+ CPU, 5 secs CPU 100%. I think this has a BUG. :) At 2014-01-10 22:21:07,"Armin Rigo" <arigo@tunes.org> wrote:
Hi,
On Fri, Jan 10, 2014 at 2:52 PM, Kenny Lasse Hoff Levinsen <kennylevinsen@gmail.com> wrote:
On 09/01/2014, at 14.30, HY <lightdarkadmin@163.com> wrote: import ctypes as C s1= "0"* 1024* 1024* 10 # mem engross add 10M bytes b1= C.create_string_buffer(s1 ) # CPU 1 core 100% and mem engross add 300M bytes ? I don't know! please talk me, thanks very match....
Fixed, thanks! It might have been a long-standing issue with memory in ctypes: memory was not promptly released, leading to the apparence of leaks.
ctypes is not nice to use. If you need C-bindings, please look at CFFI.
It's true that we usually recommend to look at CFFI instead of using ctypes, but we still look at and fix the most obvious performance problems with ctypes. The goal for us is to avoid having it run horribly more slowly than on CPython.
A bientôt,
Armin.
Hi, On Sun, Jan 12, 2014 at 6:28 AM, HY <lightdarkadmin@163.com> wrote:
I test 2f0d7dced731 memory isn't large engross. but at the AMD 5000+ CPU, 5 secs CPU 100%. I think this has a BUG. :)
Yes :-) You can see why it's slow by following the logic in pure Python in lib_pypy/_ctypes/, maybe by using just pdb. It's because every character is individually converted to a ctypes object and back before being stored into the string buffer. I guess we could add a special case to massively speed up the common "array-of-char.value = string". A bientôt, Armin.
thanks you reply my message. I think the string is pure struct, mybe should special process; want a little of change as soon as possible enablement. At 2014-01-13 04:53:56,"Armin Rigo" <arigo@tunes.org> wrote:
Hi,
On Sun, Jan 12, 2014 at 6:28 AM, HY <lightdarkadmin@163.com> wrote:
I test 2f0d7dced731 memory isn't large engross. but at the AMD 5000+ CPU, 5 secs CPU 100%. I think this has a BUG. :)
Yes :-) You can see why it's slow by following the logic in pure Python in lib_pypy/_ctypes/, maybe by using just pdb. It's because every character is individually converted to a ctypes object and back before being stored into the string buffer. I guess we could add a special case to massively speed up the common "array-of-char.value = string".
A bientôt,
Armin.
thanks you reply my message. I think the string is pure struct, mybe should special process; want a little of change as soon as possible enablement. I have a little think of a way, whether add shareptr class in ctypes or cffi? this at denseness data exchange, it can large cut down memory copy. At 2014-01-13 04:53:56,"Armin Rigo" <arigo@tunes.org> wrote:
Hi,
On Sun, Jan 12, 2014 at 6:28 AM, HY <lightdarkadmin@163.com> wrote:
I test 2f0d7dced731 memory isn't large engross. but at the AMD 5000+ CPU, 5 secs CPU 100%. I think this has a BUG. :)
Yes :-) You can see why it's slow by following the logic in pure Python in lib_pypy/_ctypes/, maybe by using just pdb. It's because every character is individually converted to a ctypes object and back before being stored into the string buffer. I guess we could add a special case to massively speed up the common "array-of-char.value = string".
A bientôt,
Armin.
Hi HY, On Mon, Jan 13, 2014 at 2:55 AM, HY <lightdarkadmin@163.com> wrote:
thanks you reply my message. I think the string is pure struct, mybe should special process; want a little of change as soon as possible enablement.
I have a little think of a way, whether add shareptr class in ctypes or cffi? this at denseness data exchange, it can large cut down memory copy.
Sorry, I don't understand you... What I said in more details: "lib_pypy/_ctypes/array.py" line 20, setvalue(): this can be done more efficiently. We can change it. It would improve the speed a lot. It is not complicated, but it needs a new function in the _rawffi module: "_rawffi.string2charp()". A bientôt, Armin.
participants (3)
-
Armin Rigo -
HY -
Kenny Lasse Hoff Levinsen