3 ms·

Not everything is reference counted in Rust. Doing stack allocations in rust is actually really easy. Stack allocations in case your not aware are incredibly fa

by bfrog 12y ago

Not everything is reference counted in Rust. Doing stack allocations in rust is actually really easy. Stack allocations in case your not aware are incredibly fast compared to anything else. The only thing faster is static allocations. In Rust, from what I've seen, you basically have the option to avoid heap allocations almost entirely which is fantastic for performance. The only other languages that come close to giving you that ability in a very explicit and deterministic way that I know of are C and C++.

burntsushi 12y ago
> In Rust, from what I've seen, you basically have the option to avoid heap allocations almost entirely which is fantastic for performance. Not really. Any time you using a `Vec<T>` or a `String` type, you'll be heap allocating. I suspect what you meant to say is that Rust does not force programmers to use some sort of garbage collection (whether it be reference counting or otherwise). That is indeed the case. I've written a fair amount of Rust code and haven't needed to use a GC at all.
- pcwalton 12y ago
  > Not really. Any time you using a `Vec<T>` or a `String` type, you'll be heap allocating. Well, we have the SmallVec type to avoid this if you can bound the size of your vectors. I would also like to introduce scratchpad allocators at some point, which should allow you to avoid heap allocations even for those. Either way, there are many ways you can avoid heap allocations entirely. For example, my NES emulator does not call malloc() during gameplay, at all.
  - burntsushi 12y ago
    Oh cool, I didn't know about `SmallVector`! That's clever. > Either way, there are many ways you can avoid heap allocations entirely. For example, my NES emulator does not call malloc() during gameplay, at all. Definitely. Executing searches from `regex!` expressions won't heap allocate either. :-) (Sans the return value, but maybe that can be avoided too.)
stcredzero 12y ago
Doing stack allocations in rust is actually really easy. Stack allocations in case your not aware are incredibly fast compared to anything else. The only thing faster is static allocations. This is also the key to programming performant Go. However, you can't really entirely avoid heap allocations, just minimize them.

by bfrog 12y ago

burntsushi 12y ago

> In Rust, from what I've seen, you basically have the option to avoid heap allocations almost entirely which is fantastic for performance. Not really. Any time you using a `Vec<T>` or a `String` type, you'll be heap allocating. I suspect what you meant to say is that Rust does not force programmers to use some sort of garbage collection (whether it be reference counting or otherwise). That is indeed the case. I've written a fair amount of Rust code and haven't needed to use a GC at all.

pcwalton 12y ago
> Not really. Any time you using a `Vec<T>` or a `String` type, you'll be heap allocating. Well, we have the SmallVec type to avoid this if you can bound the size of your vectors. I would also like to introduce scratchpad allocators at some point, which should allow you to avoid heap allocations even for those. Either way, there are many ways you can avoid heap allocations entirely. For example, my NES emulator does not call malloc() during gameplay, at all.
- burntsushi 12y ago
  Oh cool, I didn't know about `SmallVector`! That's clever. > Either way, there are many ways you can avoid heap allocations entirely. For example, my NES emulator does not call malloc() during gameplay, at all. Definitely. Executing searches from `regex!` expressions won't heap allocate either. :-) (Sans the return value, but maybe that can be avoided too.)

stcredzero 12y ago

Doing stack allocations in rust is actually really easy. Stack allocations in case your not aware are incredibly fast compared to anything else. The only thing faster is static allocations. This is also the key to programming performant Go. However, you can't really entirely avoid heap allocations, just minimize them.