I did some benchmarking of the autocommit functionality in Lucene (as opposed to in Solr, which is different). Currently, in Lucene autocommit is true by default, meaning that every time there is a flush, it is also committed. Solr adds its own layer on top of this with its commit semantics. There is a noticeable difference in memory used and speed in Lucene performance between autocommit = false and autocommit = true.
Some rough numbers using the autocommit.alg in Lucene's benchmark contrib (from trunk):
Operation round ac ram runCnt recsPerRun rec/s elapsedSec avgUsedMem avgTotalMem
[java] MAddDocs_200000 0rue2.00 1 200000 400.1 499.90 61,322,608 68,780,032
[java] MAddDocs_200000 - 1lse2.00 - - 1 - - 200000 - - 499.9 - - 400.08 - 49,373,632 - 75,018,240
[java] MAddDocs_200000 2rue2.00 1 200000 383.7 521.27 70,716,096 75,018,240
[java] MAddDocs_200000 - 3lse2.00 - - 1 - - 200000 - - 552.7 - - 361.89 - 68,069,464 - 75,018,240
The first row has autocommit = true, second is false, and then alternating. The key value is the rec/s, which is:
1. ac = true 400.1
2. ac = false 499.9
3. ac = true 383.7
4. ac = false 552.7
Notice also the diff in avgUsedMem. Adding this functionality may, perhaps, be more important to Solr's performance than the flush by RAM capability.