RE: [ZODB-Dev] Generational Caching

2005-06-08 Thread Tim Peters
[Dieter Maurer] > But with 32 bit addresses, a single process cannot use more than 4GB RAM. I expect that BIOS and/or OS often don't even allow that (e.g., user-space VM addresses are limited to 31 bits in Win32). I started working on 64-bit machines in the late 70's, so it's hard to believe that

RE: [ZODB-Dev] Generational Caching

2005-06-08 Thread Tim Peters
[Dylan Jay] > ... > Like generational garbage collection, which is I guess is one way to take > into account of frequency of use. When an object is used more than X > times it jumps to the next generation. In the next generation it is > checked less often making it more efficient than just checking

RE: [ZODB-Dev] Generational Caching

2005-06-08 Thread Dieter Maurer
Tim Peters wrote at 2005-6-7 23:05 -0400: > ... >Buying more RAM is an idea that just never gets old . But with 32 bit addresses, a single process cannot use more than 4GB RAM. -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://w

RE: [ZODB-Dev] Generational Caching

2005-06-07 Thread Tim Peters
[Chris McDonough] > One way to potentially soften the impact of cache busting by spiders > might be to allow Zope to choose a particular ZODB connection based on > request parameters (like sessionid or requesting ip address, or most > likely user agent in the case of "legitimate" spiders). This is

Re: [ZODB-Dev] Generational Caching

2005-06-07 Thread Chris McDonough
One way to potentially soften the impact of cache busting by spiders might be to allow Zope to choose a particular ZODB connection based on request parameters (like sessionid or requesting ip address, or most likely user agent in the case of "legitimate" spiders). This is a modification to Zope th