4 ms·

Memory usage is fairly moot, and will just become more and more moot. When you're watching a 3d projected HD video with 5.1 audio on your smartphone, what's us

• viraptor 16y ago
  You chose an interesting example. The movie can be played and processed quickly exactly because it has an explicit and probably hardware mapped in some places memory layout. It's processed with as few indirect operations as possible. And this was exactly the complaint in the parent post - this is not possible to do with Java. If you have a list of Integers, you have a list of Integers. (please correct me if I'm mistaken here: ) so every integer needs an explicit pointer in the list itself + the overhead of boxing. It's not the pointer to the list that matters - it's the fact, that your list takes ~4 times as much memory (pointer, lock, tag, value) - or maybe more - I don't remember the object implementation details for JVM. For scenarios where you operate on big tables of data, it matters, because it kills cache performance and uses up many times the amount of memory that you'd normally use.
  • 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 ago
      So what is a good plan to store a large in memory list of class Amount { String currencySymbol; int amount; } ?
      • brown9-2 16y ago
        Immutability 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 ago
          True but it doesn't solve my problem which is the extra pointer I need to hold the Amount object.
      • viraptor 16y ago
        Depends 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 ago
          String 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 ago
        use an int to represent the currencySymbol as well. If you need to resolve it, use a lookup table mapping ints->symbols.
        • fauigerzigerk 16y ago
          How does that help? I still have to keep that extra pointer in memory for each Amount object.
  • fauigerzigerk 16y ago
    That's exactly what I meant. In the case of int you can work around it using int[] but if you need more structure, like with a complex number type, or tuples, pairs, etc, the workarounds get really tedious. Basically what you can do is stuff it all into a large byte[] and deserialise on access. That's slow and kills productivity.
    • points 16y ago
      It's hardly a 'work around' :/ int[][] or reals int[] imaginaries int[]
      • wtallis 16y ago
        Java's multidimensional arrays aren't stored contiguously in memory because rows can be different lengths. If you have an int[][] a, then a[1] is simply a pointer to an int[]. You can't escape the excess of pointers. If you try something like having an array for each component as a substitute for an array of structs, then that places fairly strict upper bounds on the length of the arrays before which you are guaranteed to have killed cache locality.
• fauigerzigerk 16y ago
  Memory usage will never be moot as long as you have a very large cost difference between fast storage and slow mass storage. Absolute sizes don't tell you anything without comparing them to the amount of data that you want to process and index. You have chosen an example where streaming is possible. But sequential access is not what you want in databases, search engines, many forms of data analysis.