> > I think with the testmem and Ian's testpool, I think we are close to > > having a decent testing environment that is outside of the "real" > > world. The only thing I'm waiting on now is David's implementation of > > apr_pool_t as a SMS. =)
OK, OK, it's on it's way :) Patience is a virtue! > We need some decent debugging :) Yes, we do! First steps on the way real soon now! > > > I was shocked that trivial was 102-103% of > > the pool code (based on testmem results). This is *without* > > multi-threaded/unlocked allocation, which is where I believe that we're > > There is a lock in the sms framework that is enabled by default. It is > acquired when apr_sms_reset is called. This lock has to be dynamically > created as the rest of the locks. I have a decent scheme in mind which > I will post Real Soon Now(tm). > > If you disable the lock creation in apr_sms_create() [or, wait, we > moved it to apr_sms_post_init()] you should get better results. Also, > if you increase the MAX_FREE to a lot bigger you come closer to pools, > which doesn't free memory at all. With sms, you give it back to the > parent, which may hold on to it itself, or may give it back to the > system (which means that when a box has low load, the memory use > will go down). > > > going to see a benefit from SMS long-term. -- justin > > Yes. Btw, I'm doing some last mods on an sms which I called threads_sms. > It is to be the parent sms of the smss that are in different threads. > It is based on trivial and has some nice properties when it comes to > locking. I'm hoping this will be a speed improvement in a threaded > environment. I will have to commit some groundwork for use later on > for that though. Cool. david
