Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #3995
| From | Intelli2 <intelli2@mama.com> |
|---|---|
| Newsgroups | comp.programming.threads |
| Subject | Read the following paper |
| Date | 2017-12-20 16:43 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <p1elhe$cdm$3@dont-email.me> (permalink) |
Hello.. Read the following paper, because i have read it and it is interesting, this is why i have posted here: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management " Conclusion This paper presents a tracing and simulation-based experimental methodology that executes unaltered Java programs as if they used explicit memory management. We use this framework to compare the time-space performance of a range of garbage collectors to explicit memory management with the Lea memory allocator. Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management. We believe these results will be useful both for practitioners and researchers. Practitioners can use these results to guide their choice of explicitly-managed languages like C or C++, or garbage-collected languages like Java or C#. If their applications will be deployed on systems with at least three times as much RAM as needed, then garbage collection should provide reasonable performance. However, if the deployed systems will have less RAM, or if their applications will have to compete with other processes for memory, then practitioners should expect garbage collection to exact a substantial performance cost. This cost will be especially pronounced for applications whose performance is tied to their efficient use of memory, such as in-memory databases and search engines. " Read more here: https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf Thank you, Amine Moulay Ramdane.
Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread
Read the following paper Intelli2 <intelli2@mama.com> - 2017-12-20 16:43 -0500
csiph-web