If I know that a string is going to be at least X bytes in my native
extension, is there some way to set the initial capacity to avoid
memory allocations?
I see rb_str_tmp_new but I can't do that with an encoding.. could I just use
VALUE str = rb_str_tmp_new(X);
rb_enc_associate(str, enc);
Thanks
Samuel
rb_str_resize, it's documented in doc/extension.rdoc
Samuel Williams <space.ship.traveller@gmail.com> wrote:
If I know that a string is going to be at least X bytes in my native
extension, is there some way to set the initial capacity to avoid
memory allocations?
Thanks. I found the extension documentation REALLY hard to
find/navigate. This is not a criticism, just a comment from someone
who has not done much MRI native development. I constantly have to
grep for function names in the source code, headers, etc to find
anything useful. I really wish there were more documentation in
headers, even just one line, see also, etc.
On 20 March 2017 at 13:23, Eric Wong <e@80x24.org> wrote:
Samuel Williams <space.ship.traveller@gmail.com> wrote:
If I know that a string is going to be at least X bytes in my native
extension, is there some way to set the initial capacity to avoid
memory allocations?rb_str_resize, it's documented in doc/extension.rdoc
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
rb_str_resize
If I call this, it doesn't just change the capacity, it changes the
insert point for str_buf_append and similar functions, so Instead of
expected: == "<foo bar=\""Hello World"\">if x < 10</foo>"
got: "<foo bar=\""Hello
World"\">\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000if
x < 10</foo>"
I want a way to increase the capacity not the length. This way I can
avoid memory allocation and reallocation whens string grows, if I know
how big the final string would be.
On 20 March 2017 at 13:23, Eric Wong <e@80x24.org> wrote:
Samuel Williams <space.ship.traveller@gmail.com> wrote:
If I know that a string is going to be at least X bytes in my native
extension, is there some way to set the initial capacity to avoid
memory allocations?rb_str_resize, it's documented in doc/extension.rdoc
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Your question is reasonable but avoiding memory allocation won't cut it.....you can only reduce memory usage in my opinion
Sent from my Windows Phone
________________________________
From: Samuel Williams<mailto:space.ship.traveller@gmail.com>
Sent: 20/03/2017 06:36
To: Ruby users<mailto:ruby-talk@ruby-lang.org>
Subject: Re: String capacity
rb_str_resize
If I call this, it doesn't just change the capacity, it changes the
insert point for str_buf_append and similar functions, so Instead of
expected: == "<foo bar=\""Hello World"\">if x < 10</foo>"
got: "<foo bar=\""Hello
World"\">\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000if
x < 10</foo>"
I want a way to increase the capacity not the length. This way I can
avoid memory allocation and reallocation whens string grows, if I know
how big the final string would be.
On 20 March 2017 at 13:23, Eric Wong <e@80x24.org> wrote:
Samuel Williams <space.ship.traveller@gmail.com> wrote:
If I know that a string is going to be at least X bytes in my native
extension, is there some way to set the initial capacity to avoid
memory allocations?rb_str_resize, it's documented in doc/extension.rdoc
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Ah, it's a multi-step operation:
long len = RSTRING_LEN(str);
rb_str_resize(str, extra);
rb_str_set_len(str, actual);
rb_str_set_len is pretty cheap.
Samuel Williams <space.ship.traveller@gmail.com> wrote:
> rb_str_resize
If I call this, it doesn't just change the capacity, it changes the
insert point for str_buf_append and similar functions, so Instead ofexpected: == "<foo bar=\""Hello World"\">if x < 10</foo>"
got: "<foo bar=\""Hello
World"\">\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000if
x < 10</foo>"I want a way to increase the capacity not the length. This way I can
avoid memory allocation and reallocation whens string grows, if I know
how big the final string would be.
I have another question about the MRI source code. Perhaps it's just
me, but the indentation seems completely haphazard.
Some places it's spaces. Some places its tabs. Sometimes its both for
no obvious reason, e.g.
I can't be the only one who has difficulty with this?
Thanks,
Samuel
On 20 March 2017 at 17:31, Samuel Williams <space.ship.traveller@gmail.com> wrote:
Thanks. I found the extension documentation REALLY hard to
find/navigate. This is not a criticism, just a comment from someone
who has not done much MRI native development. I constantly have to
grep for function names in the source code, headers, etc to find
anything useful. I really wish there were more documentation in
headers, even just one line, see also, etc.On 20 March 2017 at 13:23, Eric Wong <e@80x24.org> wrote:
Samuel Williams <space.ship.traveller@gmail.com> wrote:
If I know that a string is going to be at least X bytes in my native
extension, is there some way to set the initial capacity to avoid
memory allocations?rb_str_resize, it's documented in doc/extension.rdoc
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
I have another question about the MRI source code. Perhaps it's just
me, but the indentation seems completely haphazard.Some places it's spaces. Some places its tabs. Sometimes its both for
no obvious reason, e.g.
Officially, I think it's mixed tabs spaces, hard tabs for 8
columns, otherwise 4 spaces. AFAIK this is the default for GNU
Emacs It's documented in the the bugs.ruby-lang.org wiki
somewhere and I've seen this style used in other projects before
I looked at Ruby.
All tabs for even levels of indentations, otherwise 4 spaces for
the last odd level of indent.
Sometimes people screw up and use only spaces, so maybe that's
what's causing the weirdness (I can't see the actual image
you're referring to with my setup).
Anyways, for vim, I use: :set ts=8 sw=4 sts=4 noexpandtab
(and most editors should be configurable)
I can't be the only one who has difficulty with this?
No. But MRI indentation is actually great compared to the
wacky indentation of some GNU projects (glibc, gnulib, ...).
For reference, all tabs (8 columns) is my preferred style,
and I'd rather make deep levels of indentation (combined with
80 column limit) to make it easier to spot refactorable code.
> Thanks. I found the extension documentation REALLY hard to
> find/navigate. This is not a criticism, just a comment from someone
> who has not done much MRI native development. I constantly have to
> grep for function names in the source code, headers, etc to find
> anything useful. I really wish there were more documentation in
> headers, even just one line, see also, etc.
ctags has always been invaluable for working with unfamiliar
(and familiar source trees), along with being handy with
git (grep/log -p/log -S), etc... That said I've been diving
into unfamiliar code for many years before I got to Ruby.
Personally, I've rarely found API docs useful; instead I prefer
code examples for showing how to use things (and MRI has a lot
of that, natively), and having the underlying source of
functions easily readable and accessible.
For a long time, I did not know about README.EXT (nowadays
extension.rdoc) but I was able to work on many C exts and MRI.
Samuel Williams <space.ship.traveller@gmail.com> wrote:
On 20 March 2017 at 17:31, Samuel Williams > <space.ship.traveller@gmail.com> wrote:
Officially, I think it's mixed tabs spaces, hard tabs for 8
columns, otherwise 4 spaces. AFAIK this is the default for GNU
Emacs It's documented in the the bugs.ruby-lang.org wiki
somewhere and I've seen this style used in other projects before
I looked at Ruby.
I've always thought of that as 'Java style', since I first saw it in Java
projects and IDEs, back when I was a Java dev (in the olden days).
Cheers
On 20 Mar 2017 17:10, "Eric Wong" <e@80x24.org> wrote:
Samuel Williams <space.ship.traveller@gmail.com> wrote:
I have another question about the MRI source code. Perhaps it's just
me, but the indentation seems completely haphazard.Some places it's spaces. Some places its tabs. Sometimes its both for
no obvious reason, e.g.
Eric, thanks for that, yeah I thought perhaps resizing it to the size
I wanted then setting the length back to 0 might work. It's too bad
there isn't a rb_str_reserve which IMHO would be really useful 
Thanks for all your other feedback. It's really helpful.
On 20 March 2017 at 20:09, Eric Wong <e@80x24.org> wrote:
Samuel Williams <space.ship.traveller@gmail.com> wrote:
I have another question about the MRI source code. Perhaps it's just
me, but the indentation seems completely haphazard.Some places it's spaces. Some places its tabs. Sometimes its both for
no obvious reason, e.g.Officially, I think it's mixed tabs spaces, hard tabs for 8
columns, otherwise 4 spaces. AFAIK this is the default for GNU
Emacs It's documented in the the bugs.ruby-lang.org wiki
somewhere and I've seen this style used in other projects before
I looked at Ruby.All tabs for even levels of indentations, otherwise 4 spaces for
the last odd level of indent.Sometimes people screw up and use only spaces, so maybe that's
what's causing the weirdness (I can't see the actual image
you're referring to with my setup).Anyways, for vim, I use: :set ts=8 sw=4 sts=4 noexpandtab
(and most editors should be configurable)I can't be the only one who has difficulty with this?
No. But MRI indentation is actually great compared to the
wacky indentation of some GNU projects (glibc, gnulib, ...).For reference, all tabs (8 columns) is my preferred style,
and I'd rather make deep levels of indentation (combined with
80 column limit) to make it easier to spot refactorable code.On 20 March 2017 at 17:31, Samuel Williams >> <space.ship.traveller@gmail.com> wrote:
> Thanks. I found the extension documentation REALLY hard to
> find/navigate. This is not a criticism, just a comment from someone
> who has not done much MRI native development. I constantly have to
> grep for function names in the source code, headers, etc to find
> anything useful. I really wish there were more documentation in
> headers, even just one line, see also, etc.ctags has always been invaluable for working with unfamiliar
(and familiar source trees), along with being handy with
git (grep/log -p/log -S), etc... That said I've been diving
into unfamiliar code for many years before I got to Ruby.Personally, I've rarely found API docs useful; instead I prefer
code examples for showing how to use things (and MRI has a lot
of that, natively), and having the underlying source of
functions easily readable and accessible.For a long time, I did not know about README.EXT (nowadays
extension.rdoc) but I was able to work on many C exts and MRI.Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Is this the link you're thinking of?
https://bugs.ruby-lang.org/projects/ruby/wiki/DeveloperHowto
...
coding style:
indent
4 for C
2 for Ruby
tab/space
Do not use TABs in ruby codes ruby-dev:19388
Use TAB instead of 8 SPs in C. (Emacs's default style)
Although I - quite possibly erroneously - recall reading a slightly
expanded version of that somewhere.
On 3/20/17, Eric Wong <e@80x24.org> wrote:
Samuel Williams <space.ship.traveller@gmail.com> wrote:
I have another question about the MRI source code. Perhaps it's just
me, but the indentation seems completely haphazard.Some places it's spaces. Some places its tabs. Sometimes its both for
no obvious reason, e.g.Officially, I think it's mixed tabs spaces, hard tabs for 8
columns, otherwise 4 spaces. AFAIK this is the default for GNU
Emacs It's documented in the the bugs.ruby-lang.org wiki
somewhere and I've seen this style used in other projects before
I looked at Ruby.