4 ms·
It's not necessarily about the size itself, but more about the fact that it has to go through a memory allocator and it has to be GC'd if that's applicable, whi
by stefncb 4y ago
It's not necessarily about the size itself, but more about the fact that it has to go through a memory allocator and it has to be GC'd if that's applicable, while a simple integer doesn't. Copies are more involved too.
Using strings for identifiers is almost always a bad idea.
- soiler 4y agoNot something I had considered. So for example a UI component that might load 3 different versions based on a string identifier, should instead use an enum which maps to integers? I say an enum because this would preserve readability of the code.
- coldpie 4y agoDo you mean an API entirely internal to your application? In that case, yes, you probably want to use integers (enums), not Strings, to choose what to display. If you are interfacing with other APIs that use Strings, it may make sense to just pass those through. For example loading files from disk or pulling up UI classes from the OS library using some String identifier or something. It's hard to say without more context.
- soiler 4y agoYes I was referring to internal APIs. Thanks
- saagarjha 4y agoThis is not true on iOS for most strings.
- stefncb 4y agoWhy is that?
- sixstringtheory 4y agoMy guess is they are talking about some optimizations iOS does to make strings more performant, like interned string constants and tagged pointers. The majority of string usage probably falls under those. Working with dynamically allocated strings, like reading from files, rendering from data bytes, working with C strings or building formatted strings, might have worse performance characteristics.