Skip to main content
Code Review

Return to Answer

replaced http://stackoverflow.com/ with https://stackoverflow.com/
Source Link

I tried this on 2 different computers and I'm getting inconsistent results. Sometimes the first method is faster, sometimes the other. It also depends on the number of iterations, with a pretty wild spread. I think the outcome depends on:

  • the JVM implementation and version, especially the default garbage collector settings and behavior
  • the currently active garbage collector settings

The most important point is not so much the processing time, but the implications in terms of memory use: the first method will store N instances of String on the heap while the other will store only 1. The difference in processing time is more of an otherwise meaningless trivia.


While on the subject of caching Strings, I think it's worth mentioning about the technique of String interning. For example if your application loads 100k records from a database and you use rs.getString("city") for each record when in fact there are only 10 distinct city names, then you could be wasting a lot of memory. In such situation, storing the results of rs.getString("city").intern() could reduce memory usage dramatically, at the expense of using more PermGen space instead of the heap.

As @h-j-k added in comments:

To add on: String interning in Java 7 happens in heap, not PermGen anymore: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931 (I am also advocating testing this too within the context of the given question)

Considering the memory usage, I think it's safe to say that in your real-world application you should go either with your own Map cache or interning. As you posted in a comment, here's an excellent post here's an excellent post comparing the performance of these two options. However, keep in mind that the result of such benchmark will always depend on your JVM implementation and its tuning options. Managing your own cache could be tedious sometimes in a realistic situation. If the speed of this is of real concern in your application, you might want to repeat the benchmark in the application itself, rather than just in an isolated experiment.

I tried this on 2 different computers and I'm getting inconsistent results. Sometimes the first method is faster, sometimes the other. It also depends on the number of iterations, with a pretty wild spread. I think the outcome depends on:

  • the JVM implementation and version, especially the default garbage collector settings and behavior
  • the currently active garbage collector settings

The most important point is not so much the processing time, but the implications in terms of memory use: the first method will store N instances of String on the heap while the other will store only 1. The difference in processing time is more of an otherwise meaningless trivia.


While on the subject of caching Strings, I think it's worth mentioning about the technique of String interning. For example if your application loads 100k records from a database and you use rs.getString("city") for each record when in fact there are only 10 distinct city names, then you could be wasting a lot of memory. In such situation, storing the results of rs.getString("city").intern() could reduce memory usage dramatically, at the expense of using more PermGen space instead of the heap.

As @h-j-k added in comments:

To add on: String interning in Java 7 happens in heap, not PermGen anymore: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931 (I am also advocating testing this too within the context of the given question)

Considering the memory usage, I think it's safe to say that in your real-world application you should go either with your own Map cache or interning. As you posted in a comment, here's an excellent post comparing the performance of these two options. However, keep in mind that the result of such benchmark will always depend on your JVM implementation and its tuning options. Managing your own cache could be tedious sometimes in a realistic situation. If the speed of this is of real concern in your application, you might want to repeat the benchmark in the application itself, rather than just in an isolated experiment.

I tried this on 2 different computers and I'm getting inconsistent results. Sometimes the first method is faster, sometimes the other. It also depends on the number of iterations, with a pretty wild spread. I think the outcome depends on:

  • the JVM implementation and version, especially the default garbage collector settings and behavior
  • the currently active garbage collector settings

The most important point is not so much the processing time, but the implications in terms of memory use: the first method will store N instances of String on the heap while the other will store only 1. The difference in processing time is more of an otherwise meaningless trivia.


While on the subject of caching Strings, I think it's worth mentioning about the technique of String interning. For example if your application loads 100k records from a database and you use rs.getString("city") for each record when in fact there are only 10 distinct city names, then you could be wasting a lot of memory. In such situation, storing the results of rs.getString("city").intern() could reduce memory usage dramatically, at the expense of using more PermGen space instead of the heap.

As @h-j-k added in comments:

To add on: String interning in Java 7 happens in heap, not PermGen anymore: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931 (I am also advocating testing this too within the context of the given question)

Considering the memory usage, I think it's safe to say that in your real-world application you should go either with your own Map cache or interning. As you posted in a comment, here's an excellent post comparing the performance of these two options. However, keep in mind that the result of such benchmark will always depend on your JVM implementation and its tuning options. Managing your own cache could be tedious sometimes in a realistic situation. If the speed of this is of real concern in your application, you might want to repeat the benchmark in the application itself, rather than just in an isolated experiment.

replaced http://codereview.stackexchange.com/ with https://codereview.stackexchange.com/
Source Link

I tried this on 2 different computers and I'm getting inconsistent results. Sometimes the first method is faster, sometimes the other. It also depends on the number of iterations, with a pretty wild spread. I think the outcome depends on:

  • the JVM implementation and version, especially the default garbage collector settings and behavior
  • the currently active garbage collector settings

The most important point is not so much the processing time, but the implications in terms of memory use: the first method will store N instances of String on the heap while the other will store only 1. The difference in processing time is more of an otherwise meaningless trivia.


While on the subject of caching Strings, I think it's worth mentioning about the technique of String interning. For example if your application loads 100k records from a database and you use rs.getString("city") for each record when in fact there are only 10 distinct city names, then you could be wasting a lot of memory. In such situation, storing the results of rs.getString("city").intern() could reduce memory usage dramatically, at the expense of using more PermGen space instead of the heap.

As @h-j-k @h-j-k added in comments:

To add on: String interning in Java 7 happens in heap, not PermGen anymore: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931 (I am also advocating testing this too within the context of the given question)

Considering the memory usage, I think it's safe to say that in your real-world application you should go either with your own Map cache or interning. As you posted in a comment, here's an excellent post comparing the performance of these two options. However, keep in mind that the result of such benchmark will always depend on your JVM implementation and its tuning options. Managing your own cache could be tedious sometimes in a realistic situation. If the speed of this is of real concern in your application, you might want to repeat the benchmark in the application itself, rather than just in an isolated experiment.

I tried this on 2 different computers and I'm getting inconsistent results. Sometimes the first method is faster, sometimes the other. It also depends on the number of iterations, with a pretty wild spread. I think the outcome depends on:

  • the JVM implementation and version, especially the default garbage collector settings and behavior
  • the currently active garbage collector settings

The most important point is not so much the processing time, but the implications in terms of memory use: the first method will store N instances of String on the heap while the other will store only 1. The difference in processing time is more of an otherwise meaningless trivia.


While on the subject of caching Strings, I think it's worth mentioning about the technique of String interning. For example if your application loads 100k records from a database and you use rs.getString("city") for each record when in fact there are only 10 distinct city names, then you could be wasting a lot of memory. In such situation, storing the results of rs.getString("city").intern() could reduce memory usage dramatically, at the expense of using more PermGen space instead of the heap.

As @h-j-k added in comments:

To add on: String interning in Java 7 happens in heap, not PermGen anymore: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931 (I am also advocating testing this too within the context of the given question)

Considering the memory usage, I think it's safe to say that in your real-world application you should go either with your own Map cache or interning. As you posted in a comment, here's an excellent post comparing the performance of these two options. However, keep in mind that the result of such benchmark will always depend on your JVM implementation and its tuning options. Managing your own cache could be tedious sometimes in a realistic situation. If the speed of this is of real concern in your application, you might want to repeat the benchmark in the application itself, rather than just in an isolated experiment.

I tried this on 2 different computers and I'm getting inconsistent results. Sometimes the first method is faster, sometimes the other. It also depends on the number of iterations, with a pretty wild spread. I think the outcome depends on:

  • the JVM implementation and version, especially the default garbage collector settings and behavior
  • the currently active garbage collector settings

The most important point is not so much the processing time, but the implications in terms of memory use: the first method will store N instances of String on the heap while the other will store only 1. The difference in processing time is more of an otherwise meaningless trivia.


While on the subject of caching Strings, I think it's worth mentioning about the technique of String interning. For example if your application loads 100k records from a database and you use rs.getString("city") for each record when in fact there are only 10 distinct city names, then you could be wasting a lot of memory. In such situation, storing the results of rs.getString("city").intern() could reduce memory usage dramatically, at the expense of using more PermGen space instead of the heap.

As @h-j-k added in comments:

To add on: String interning in Java 7 happens in heap, not PermGen anymore: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931 (I am also advocating testing this too within the context of the given question)

Considering the memory usage, I think it's safe to say that in your real-world application you should go either with your own Map cache or interning. As you posted in a comment, here's an excellent post comparing the performance of these two options. However, keep in mind that the result of such benchmark will always depend on your JVM implementation and its tuning options. Managing your own cache could be tedious sometimes in a realistic situation. If the speed of this is of real concern in your application, you might want to repeat the benchmark in the application itself, rather than just in an isolated experiment.

added 17 characters in body
Source Link
janos
  • 112.9k
  • 15
  • 154
  • 396

I tried this on 2 different computers and I'm getting inconsistent results. Sometimes the first method is faster, sometimes the other. It also depends on the number of iterations, with a pretty wild spread. I think the outcome depends on:

  • the JVM implementation and version, especially the default garbage collector settings and behavior
  • the currently active garbage collector settings

The most important point is not so much the processing time, but the implications in terms of memory use: the first method will store N instances of String on the heap while the other will store only 1. The difference in processing time is more of an otherwise meaningless trivia.


While on the subject of caching Strings, I think it's worth mentioning about the technique of String interning. For example if your application loads 100k records from a database and you use rs.getString("city") for each record when in fact there are only 10 distinct city names, then you could be wasting a lot of memory. In such situation, storing the results of rs.getString("city").intern() could reduce memory usage dramatically, at the expense of using more PermGen space instead of the heap.

As @h-j-k added in comments:

To add on: String interning in Java 7 happens in heap, not PermGen anymore: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931 (I am also advocating testing this too within the context of the given question)

Considering the memory usage, I think it's safe to say that in your real-world application you should go either with your own Map cache or interning. As you posted in a comment, here's an excellent post comparing the performance of these two options. However, keep in mind that the result of such benchmark will always depend on your JVM implementation and its tuning options. Managing your own cache could be tedious sometimes in a realistic situation. If the speed of this is of real concern in your application, you might want to repeat the benchmark in the application itself, rather than just in an isolated experiment.

I tried this on 2 different computers and I'm getting inconsistent results. Sometimes the first method is faster, sometimes the other. It also depends on the number of iterations, with a pretty wild spread. I think the outcome depends on:

  • the JVM implementation and version, especially the default garbage collector settings and behavior
  • the active garbage collector settings

The most important point is not so much the processing time, but the implications in terms of memory use: the first method will store N instances of String on the heap while the other will store only 1. The difference in processing time is more of an otherwise meaningless trivia.

While on the subject of caching Strings, I think it's worth mentioning about the technique of String interning. For example if your application loads 100k records from a database and you use rs.getString("city") for each record when in fact there are only 10 distinct city names, then you could be wasting a lot of memory. In such situation, storing the results of rs.getString("city").intern() could reduce memory usage dramatically, at the expense of using more PermGen space instead of the heap.

As @h-j-k added in comments:

To add on: String interning in Java 7 happens in heap, not PermGen anymore: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931 (I am also advocating testing this too within the context of the given question)

Considering the memory usage, I think it's safe to say that in your real-world application you should go either with your own Map cache or interning. As you posted in a comment, here's an excellent post comparing the performance of these two options. However, keep in mind that the result of such benchmark will always depend on your JVM implementation and its tuning options. Managing your own cache could be tedious sometimes in a realistic situation. If the speed of this is of real concern in your application, you might want to repeat the benchmark in the application itself, rather than just in an isolated experiment.

I tried this on 2 different computers and I'm getting inconsistent results. Sometimes the first method is faster, sometimes the other. It also depends on the number of iterations, with a pretty wild spread. I think the outcome depends on:

  • the JVM implementation and version, especially the default garbage collector settings and behavior
  • the currently active garbage collector settings

The most important point is not so much the processing time, but the implications in terms of memory use: the first method will store N instances of String on the heap while the other will store only 1. The difference in processing time is more of an otherwise meaningless trivia.


While on the subject of caching Strings, I think it's worth mentioning about the technique of String interning. For example if your application loads 100k records from a database and you use rs.getString("city") for each record when in fact there are only 10 distinct city names, then you could be wasting a lot of memory. In such situation, storing the results of rs.getString("city").intern() could reduce memory usage dramatically, at the expense of using more PermGen space instead of the heap.

As @h-j-k added in comments:

To add on: String interning in Java 7 happens in heap, not PermGen anymore: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931 (I am also advocating testing this too within the context of the given question)

Considering the memory usage, I think it's safe to say that in your real-world application you should go either with your own Map cache or interning. As you posted in a comment, here's an excellent post comparing the performance of these two options. However, keep in mind that the result of such benchmark will always depend on your JVM implementation and its tuning options. Managing your own cache could be tedious sometimes in a realistic situation. If the speed of this is of real concern in your application, you might want to repeat the benchmark in the application itself, rather than just in an isolated experiment.

added 726 characters in body
Source Link
janos
  • 112.9k
  • 15
  • 154
  • 396
Loading
added 305 characters in body
Source Link
janos
  • 112.9k
  • 15
  • 154
  • 396
Loading
Source Link
janos
  • 112.9k
  • 15
  • 154
  • 396
Loading
lang-java

AltStyle によって変換されたページ (->オリジナル) /