4 ms·
int[] is fairly tight. If you're going for performance or optimum memory usage, using lists and boxing isn't going to be a good plan. I once wrote an x86 emula
by points 16y ago
int[] is fairly tight. If you're going for performance or optimum memory usage, using lists and boxing isn't going to be a good plan.
I once wrote an x86 emulator in java and later an ARM emulator (long story). It ran fast enough :)
- fauigerzigerk 16y agoSo what is a good plan to store a large in memory list of class Amount { String currencySymbol; int amount; } ?
- brown9-2 16y agoImmutability would allow you to re-use Amount instances; this is what the Integer class does for "common" int values (I believe -127 thru 128).
- fauigerzigerk 16y agoTrue but it doesn't solve my problem which is the extra pointer I need to hold the Amount object.
- viraptor 16y agoDepends on the value of "large". But two main points would be: 1. Intern the strings. 2. Store only indexes and operate on a "main list" of currencySymbols[i] and amount[i]. (to reduce the overhead of boxed ints) Of course this is not always possible... Every scenario has its own solution, I guess.
- fauigerzigerk 16y agoString interning is a side issue here. But what you suggest is basically to destructure all structured types into lots of individual arrays. That's a technique I'm using frequently. But it's a very tedious and error prone thing to do once the data structures get a little more complex. But I still agree that it's sometimes a workable solution. It's not a workable solution if Amount objects are part of other structures. Consider this: class Point { int x; int y; } class Rect { Point a; Point b; } List<Rect> list ...
- elblanco 16y agouse an int to represent the currencySymbol as well. If you need to resolve it, use a lookup table mapping ints->symbols.
- fauigerzigerk 16y agoHow does that help? I still have to keep that extra pointer in memory for each Amount object.
- elblanco 16y agoYou'll always need a pointer to the objects, no matter the language. But you'll save on having to store a pointer from those objects to a string object, which with 2 unicode characters (assuming Java strings are null terminated) saves you a total of (I believe Java still uses 64-bit pointers no?), 8bytes for the pointer to the string, 16 for the string, 24 bytes per object minus the int which is 4 bytes so 20 bytes per object. Assuming these are transaction objects, that's a crap-ton if you have lots of transactions.
- fauigerzigerk 16y agoLet's leave the string issue aside. It has nothing to do with the point I was trying to make. Consider the example I gave in another reply: class Point { int x; int y; } class Rect { Point a; Point b; } List<Rect> list ... In Java, this list of Rect objects contains three pointers that a functionally equivalent list in C++, C# or Go would not have to hold.
- elblanco 16y agoAre you talking about pointers to objects? Are there any languages that allow you to have objects that aren't pointed to? Maybe C-style structs? Is that what you are talking about? Complaining about pointers to objects is like complaining about the wasted byte at the end of a null-terminated string. There's a general move away from structs for some reason. My guess is that structs do have a problem with platform independence if you rely too much on the primitive types being consistent across platforms. An int being a 4-byte chunk of memory isn't always true (actually, if memory serves, an int was supposed to be standardized as the word length of the local system, so it could be all kinds of oddball lengths, like 24-bits). So my guess is that most modern languages looked at this problem and decided that cross-platform compatibility is more important. But to be honest, with a virtualized run-time, like the JVM, you can define the primitive types as a standardized abstraction on-top of the runtime system...so in that sense it doesn't really make all the much sense to not have them, except maybe to adhere to principles of data hiding or some such. However, strictly speaking, the code you provided would probably be a similar pointerfest in C++ or C# since you aren't using structs, I don't know enough about Go to reply intelligently about that language.
- mahmud 16y agoDon't use int for money. Use BigDecimal. I know performance is an issue, but you can always find non-hackish solutions: like a memory upgrade from management, because you're writing safe, clean code :-)
- fauigerzigerk 16y agoBigDecimal uses 10 times as much memory as an int but I didn't intend to properly model currency amounts anyway.
- mahmud 16y ago:-) http://img.thedailywtf.com/images/200902/errord/DSC00669.JPG http://img.thedailywtf.com/images/200902/errord/DSC00669.JPG
- points 16y agoString[] currencySymbols; int[] amounts; ?
- scott_s 16y agoYes, but now there is not language-enforced relationship between the two. That currencySymbols[i] and amounts[i] are, in the mind of the programmer, two fields in the same object is no longer expressed in the language itself.