The developer of JCS (Aaron Smuts) is claiming that "JCS LRU is almost twice as fast." He was referring to EHCache. He also says "The JCS LRU is faster than any other implementation that I know of. It always has been. It doesn't seem to have any bugs in its current version . ." Can you clarify how you ran your tests?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just started this page which compares JCS and EHCache. I included my test class on the page. My initial tests show that the LRU Memory store in JCS 1.2.7.0 is about twice as fast as the current head version of EHCache (1.2-beta4). I'm working on additional tests. You can read more here:
Alright. Enough. Everybody understands. You think JCS is better, faster, stronger, etc. ad nauseum. This is NOT a forum about JCS, this is a forum about EHCache. The more your reply here, the less desire there is to evaluate JCS. I suggest you quick your *attacks* on EHCache in this forum and concentrate on promoting your product in a positive way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I cannot agree more with James Tefler and jwisard. Please don't use these forums for your publicity.
You have lot of other avenues out side (you have your own website) for your claims and for publicity. PLEASE DON'T USE THESE FORUMS FOR THAT PURPOSE. They're for good technical discussion.
While I look forward for good technical discussion, it serves no purpose to say the same thing again and again and in response to every possible question in the forum.
Hope you understand.
Thanks.
- Surya Suravarapu
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Substantiate your claim that EHCache is faster or remove it from your site. Your benchmark test description is far too vague to be reproducible. Provide configuration details and the precise test code.
You can find some information about my tests and the results here:
Please let me know if there is some problem with my tests which indicate that JCS is twice as fast as EHCache at gets and puts when the data is in the cache and the size limit has not been reached.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your performance comparison is quite useful and I'm looking forward to seeing more. I'm not in control of the web content, so I can't alter that.
However, in general I find this latest post of yours to be quite distinct from your recent efforts on these discussion boards. While your tone is still petulant, the content is at least relevant to the topic. In contrast, most of your posts to the EHCache forums are irrelevant to the topics of discussion, as people post to this board seeking EHCache help, not questioning whether they should give up and use JCS instead. In fact, your content is more similar to spam than you would like or admit to.
You have a medium for JCS information - http://jakarta.apache.org/jcs/. I am encouraged that your performance page uses this, and that you direct others to it from a thread that is directly related to the subject of comparative performance. This suggests to me that you are aware of the general etiquette of such situations, and I hope that now you've vented your spleen across these discussion boards once you won't feel the need to continue.
Again, I look forward to more discussion on performance, and if you post other comparisons I'll look at those too.
Regards,
James Telfer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I keep running tests and sometimes JCS and EH are very close on almost all operations and other times EH comes out slightly ahead, and other times JCS comes out far ahead. It's very difficult to get clear data. (Ultimately, we are talking about performance differences that don't really matter.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't consider my posts to be spam. Every single one of my posts is relevant to the question at hand. I was just offering the same kind of solution to EH bugs as EH offered to JCS bugs. EH said use JCS, and, well, I'm suggesting a similar kind of solution. I provide a universal EHCache bug fix: use JCS instead. . . .
In all seriousness, EH presents itself as a simplified JCS, so if your users want additional features, then using JCS sounds like a good suggestion. There were specific feautures that EH users were looking for that JCS includes, such as element level configuration. . . . I don't have any additional advice and no one seems to appreciate it anyway, so I don't intend to post any additional suggestions any time soon.
Too bad we cannpt resolve the unsubstantiated EH claims. Although any performance differences between the two caches will be largely irrelevant to overall application performance, claims should be substantiated, and any differences should not be exaggerated.
Good luck.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aaron has made quite a few attempts to contact me over the past two weeks. Unfortunately I was offline.
At the time the tests were done they were valid. A year ago whirlycache did a performance comparison of the memory stores (http://whirlycache.dev.java.net/) and found that OSCache and JCS were about tied for slowest memory store. It also showed that whirlycache was faster than ehcache as a memory store. At the time ehcache was second behind whirlycache.
As development has proceeded on 1.2, my concern, and I suspect the concern of most users, is to make sure that performance does not regress. The addition of cache event listeners, and different eviction algorithms have different performance characteristics. If you do with the defaults ehcache should be just as fast for that configuration as it ever was.
I am not that interested in whether JCS's latest version has a faster memory store. I do however accept Aaron's complaint that two year old performance numbers are no longer relevant. Accordingly I have removed them, along with most references to JCS, in the home page and the 1.2 documentation.
Any astute reader of the ehcache documentation will note that ehcache began as a fork of JCS and quickly became a rewrite. The reason that happened in the first place was a) because no one responded to the patches submitted and b) Gavin King was very frustrated that caching bugs would affect the adoption of hibernate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The developer of JCS (Aaron Smuts) is claiming that "JCS LRU is almost twice as fast." He was referring to EHCache. He also says "The JCS LRU is faster than any other implementation that I know of. It always has been. It doesn't seem to have any bugs in its current version . ." Can you clarify how you ran your tests?
I just started this page which compares JCS and EHCache. I included my test class on the page. My initial tests show that the LRU Memory store in JCS 1.2.7.0 is about twice as fast as the current head version of EHCache (1.2-beta4). I'm working on additional tests. You can read more here:
http://jakarta.apache.org/jcs/JCSvsEHCache.html
Alright. Enough. Everybody understands. You think JCS is better, faster, stronger, etc. ad nauseum. This is NOT a forum about JCS, this is a forum about EHCache. The more your reply here, the less desire there is to evaluate JCS. I suggest you quick your *attacks* on EHCache in this forum and concentrate on promoting your product in a positive way.
Aaron,
I cannot agree more with James Tefler and jwisard. Please don't use these forums for your publicity.
You have lot of other avenues out side (you have your own website) for your claims and for publicity. PLEASE DON'T USE THESE FORUMS FOR THAT PURPOSE. They're for good technical discussion.
While I look forward for good technical discussion, it serves no purpose to say the same thing again and again and in response to every possible question in the forum.
Hope you understand.
Thanks.
- Surya Suravarapu
Substantiate your claim that EHCache is faster or remove it from your site. Your benchmark test description is far too vague to be reproducible. Provide configuration details and the precise test code.
You can find some information about my tests and the results here:
http://jakarta.apache.org/jcs/JCSvsEHCache.html
Please let me know if there is some problem with my tests which indicate that JCS is twice as fast as EHCache at gets and puts when the data is in the cache and the size limit has not been reached.
Aaron,
Your performance comparison is quite useful and I'm looking forward to seeing more. I'm not in control of the web content, so I can't alter that.
However, in general I find this latest post of yours to be quite distinct from your recent efforts on these discussion boards. While your tone is still petulant, the content is at least relevant to the topic. In contrast, most of your posts to the EHCache forums are irrelevant to the topics of discussion, as people post to this board seeking EHCache help, not questioning whether they should give up and use JCS instead. In fact, your content is more similar to spam than you would like or admit to.
You have a medium for JCS information - http://jakarta.apache.org/jcs/. I am encouraged that your performance page uses this, and that you direct others to it from a thread that is directly related to the subject of comparative performance. This suggests to me that you are aware of the general etiquette of such situations, and I hope that now you've vented your spleen across these discussion boards once you won't feel the need to continue.
Again, I look forward to more discussion on performance, and if you post other comparisons I'll look at those too.
Regards,
James Telfer
I keep running tests and sometimes JCS and EH are very close on almost all operations and other times EH comes out slightly ahead, and other times JCS comes out far ahead. It's very difficult to get clear data. (Ultimately, we are talking about performance differences that don't really matter.)
I don't consider my posts to be spam. Every single one of my posts is relevant to the question at hand. I was just offering the same kind of solution to EH bugs as EH offered to JCS bugs. EH said use JCS, and, well, I'm suggesting a similar kind of solution. I provide a universal EHCache bug fix: use JCS instead. . . .
In all seriousness, EH presents itself as a simplified JCS, so if your users want additional features, then using JCS sounds like a good suggestion. There were specific feautures that EH users were looking for that JCS includes, such as element level configuration. . . . I don't have any additional advice and no one seems to appreciate it anyway, so I don't intend to post any additional suggestions any time soon.
Too bad we cannpt resolve the unsubstantiated EH claims. Although any performance differences between the two caches will be largely irrelevant to overall application performance, claims should be substantiated, and any differences should not be exaggerated.
Good luck.
Aaron has made quite a few attempts to contact me over the past two weeks. Unfortunately I was offline.
At the time the tests were done they were valid. A year ago whirlycache did a performance comparison of the memory stores (http://whirlycache.dev.java.net/) and found that OSCache and JCS were about tied for slowest memory store. It also showed that whirlycache was faster than ehcache as a memory store. At the time ehcache was second behind whirlycache.
As development has proceeded on 1.2, my concern, and I suspect the concern of most users, is to make sure that performance does not regress. The addition of cache event listeners, and different eviction algorithms have different performance characteristics. If you do with the defaults ehcache should be just as fast for that configuration as it ever was.
I am not that interested in whether JCS's latest version has a faster memory store. I do however accept Aaron's complaint that two year old performance numbers are no longer relevant. Accordingly I have removed them, along with most references to JCS, in the home page and the 1.2 documentation.
Any astute reader of the ehcache documentation will note that ehcache began as a fork of JCS and quickly became a rewrite. The reason that happened in the first place was a) because no one responded to the patches submitted and b) Gavin King was very frustrated that caching bugs would affect the adoption of hibernate.