5 ms·

I'm a fan of Rust, but the practice of allocating strings on the stack in fixed-sized buffers is one of the biggest mistakes of C culture. Perhaps you could jus

I'm a fan of Rust, but the practice of allocating strings on the stack in fixed-sized buffers is one of the biggest mistakes of C culture. Perhaps you could just picked a poor example?

fleitz 13y ago
Stack allocation is kind of like inlining, the more you use it the faster your program gets.
- MichaelGG 13y ago
  I know this may have been tongue-in-cheek, but on the CLR, inlining functions makes a massive difference. That is, using F#'s forced inlining capabilities to generate massive functions (many KB of IL) resulted in much better runtimes than having even a couple of small functions called (which "should" be inlined by the CLR; MS tells us we should just rely on the JIT for these cases).
MichaelGG 13y ago
That's more a problem of unsafe manipulation. Allocating a safe length-prefixed string should not be an issue. Or, arrays. Take .NET's String.Split function which takes a char array. If you pass in a new array each time, there's a whole heap-alloc for no reason. Or Tuples. Or closure objects. Things like that do add up (GC cost, even though small short-lived objects are fast, it isn't zero), and escape analysis/stack alloc can make a huge difference, sometimes. I've come to this conclusion while writing a "high-speed" indexer program where manually avoiding tiny allocations in certain areas provided double-digit percent improvements. I wish I had kept proper notes.
- marshray 13y ago
  Yes, absolutely, allocate everything possible on the stack. But strings are the poster child for dynamic memory allocation. We only very rarely know a good upper limit on the size of the actual strings at the time the code is written, yet C programmers have shipped endless numbers of bugs thinking they did.
  - gsg 13y ago
    Stack allocation needn't be unprincipled hackery. You can keep a buffer of static size on the stack (resp. in the struct) and fall back to dynamic allocation only if there is insufficient space.
    - marshray 13y ago
      Yeah I've written that code a bunch of times. A real pain in the butt to get right and to test.
      - gsg 13y ago
        I bet. All the more reason for the implementation to provide it for you - possibly transparently.

I'm a fan of Rust, but the practice of allocating strings on the stack in fixed-sized buffers is one of the biggest mistakes of C culture. Perhaps you could just picked a poor example?

fleitz 13y ago

Stack allocation is kind of like inlining, the more you use it the faster your program gets.

MichaelGG 13y ago
I know this may have been tongue-in-cheek, but on the CLR, inlining functions makes a massive difference. That is, using F#'s forced inlining capabilities to generate massive functions (many KB of IL) resulted in much better runtimes than having even a couple of small functions called (which "should" be inlined by the CLR; MS tells us we should just rely on the JIT for these cases).

MichaelGG 13y ago

That's more a problem of unsafe manipulation. Allocating a safe length-prefixed string should not be an issue. Or, arrays. Take .NET's String.Split function which takes a char array. If you pass in a new array each time, there's a whole heap-alloc for no reason. Or Tuples. Or closure objects. Things like that do add up (GC cost, even though small short-lived objects are fast, it isn't zero), and escape analysis/stack alloc can make a huge difference, sometimes. I've come to this conclusion while writing a "high-speed" indexer program where manually avoiding tiny allocations in certain areas provided double-digit percent improvements. I wish I had kept proper notes.

marshray 13y ago
Yes, absolutely, allocate everything possible on the stack. But strings are the poster child for dynamic memory allocation. We only very rarely know a good upper limit on the size of the actual strings at the time the code is written, yet C programmers have shipped endless numbers of bugs thinking they did.
- gsg 13y ago
  Stack allocation needn't be unprincipled hackery. You can keep a buffer of static size on the stack (resp. in the struct) and fall back to dynamic allocation only if there is insufficient space.
  - marshray 13y ago
    Yeah I've written that code a bunch of times. A real pain in the butt to get right and to test.
    - gsg 13y ago
      I bet. All the more reason for the implementation to provide it for you - possibly transparently.