[Zope-dev] z3 server+publication refactor for z2
Hi, Sidnei has been working on the Zope 2 publication-refactor branch where he's allowed the use of the Zope 3 Twisted-based server, and of a Zope 3 based publication process. I'd like to see this merge branched in Zope 2 trunk because I'd like Zope 2.10 to be Twisted-based. What's missing from the branch preventing this? What problems have been encountered? (This query is a reaction to my diving in to current asyncore+medusa +ThreadedAsync+PubCore that gives me nightmares when I realize I'll have to implement new server types or new stuff more akin to the ZEO storage server.) Thanks, Florent PS: what do people think of changing ZEO so that it integrates with Twisted properly instead of relying on a private event loop hack [please move to zodb-dev if you answer this] -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3 server+publication refactor for z2
--On 13. April 2006 11:46:20 +0200 Florent Guillaume [EMAIL PROTECTED] wrote: Hi, Sidnei has been working on the Zope 2 publication-refactor branch where he's allowed the use of the Zope 3 Twisted-based server, and of a Zope 3 based publication process. I'd like to see this merge branched in Zope 2 trunk because I'd like Zope 2.10 to be Twisted-based. What's missing from the branch preventing this? What problems have been encountered? The question is: how complete and stable is this stuff? Does it replace the current implementation or is it an optional feature as in Zope 3.2? If the implementation is half-backed then it will be a show-stopper, otherwise we need some confidence that it works as it should with breaking something. Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development and consulting pgpJb3A5FRF8H.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3 server+publication refactor for z2
On 13.04.2006, at 11:55, Andreas Jung wrote: --On 13. April 2006 11:46:20 +0200 Florent Guillaume [EMAIL PROTECTED] wrote: Hi, Sidnei has been working on the Zope 2 publication-refactor branch where he's allowed the use of the Zope 3 Twisted-based server, and of a Zope 3 based publication process. I'd like to see this merge branched in Zope 2 trunk because I'd like Zope 2.10 to be Twisted-based. What's missing from the branch preventing this? What problems have been encountered? The question is: how complete and stable is this stuff? Does it replace the current implementation or is it an optional feature as in Zope 3.2? twisted is the standard server in zope 3.2 - zserver is optional If the implementation is half-backed then it will be a show- stopper, otherwise we need some confidence that it works as it should with breaking something. Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development and consulting ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: z3 server+publication refactor for z2
On Thu, Apr 13, 2006 at 11:46:20AM +0200, Florent Guillaume wrote: | Hi, | | Sidnei has been working on the Zope 2 publication-refactor branch | where he's allowed the use of the Zope 3 Twisted-based server, and of | a Zope 3 based publication process. | | I'd like to see this merge branched in Zope 2 trunk because I'd like | Zope 2.10 to be Twisted-based. What's missing from the branch | preventing this? What problems have been encountered? Well, the biggest is making an adapter for the Zope 3 request so that it implements the same interface as the Zope 2 request. Other than that, it was pretty much working. Oh, and now I recall, we don't have 'streaming', 'chunked', and 'gzipping' yet, though the latter two would be easily implemented as wsgi middleware (could even use the implementation from django/turbogears). That's the second biggest :) | (This query is a reaction to my diving in to current asyncore+medusa | +ThreadedAsync+PubCore that gives me nightmares when I realize I'll | have to implement new server types or new stuff more akin to the ZEO | storage server.) It's not that bad :) | Thanks, | Florent | | PS: what do people think of changing ZEO so that it integrates with | Twisted properly instead of relying on a private event loop hack | [please move to zodb-dev if you answer this] -- Sidnei da Silva Enfold Systems, Inc. http://enfoldsystems.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: z3 server+publication refactor for z2
Sidnei da Silva wrote: On Thu, Apr 13, 2006 at 11:46:20AM +0200, Florent Guillaume wrote: | Hi, | | Sidnei has been working on the Zope 2 publication-refactor branch | where he's allowed the use of the Zope 3 Twisted-based server, and of | a Zope 3 based publication process. | | I'd like to see this merge branched in Zope 2 trunk because I'd like | Zope 2.10 to be Twisted-based. What's missing from the branch | preventing this? What problems have been encountered? Well, the biggest is making an adapter for the Zope 3 request so that it implements the same interface as the Zope 2 request. Other than that, it was pretty much working. We might not need a special request type. We could try to continue to use ZPublisher's request implementation, at least for now. In WSGI, the application gets the env and streams. In Zope 3, this is the WSGIPublisherApplication (see zope.app.wsgi). It is responsible for creating the request, but it chooses to delegate to an HTTP request factory. This factory decides, based on certian rules, whether we're dealing with a plain HTTP/WebDAV request or XML-RPC or browser etc. In Zope 2, this factory (or the WSGIPublisherApplciation itself) could simply create a ZPublisher request object. After creating the request, the WSGIPublisherApplication would turn the request over to ZPublisher.Publish.publish and sends it on its normal path. This is the small solution in which we provide a WSGI-capable frontend to the ZPublisher. The big solution would be to replace ZPublisher with zope.publisher and a custom Zope2-oriented publication + appropriate traversers. In this case I wouldn't advise for adapting the Zope 3 request to a Zope 2 request. I would rather introduce a new request type, IZope2Request, based on zope.publisher's IBrowserRequest, that provides all the additional Zope 2 API. I think the big solution would take a considerable effort. It's less than three weeks before feature freeze. That is very little time even for the small solution. Oh, and now I recall, we don't have 'streaming', 'chunked', We have something along those lines. Jim can say more. and 'gzipping' yet, though the latter two would be easily implemented as wsgi middleware (could even use the implementation from django/turbogears). Yeah. Good idea. Perhaps we can see if we can create a common wsgzip package or something that is open to all WSGI-capable Python frameworks. Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: z3 server+publication refactor for z2
--On 13. April 2006 15:39:06 +0200 Philipp von Weitershausen [EMAIL PROTECTED] wrote: This is the small solution in which we provide a WSGI-capable frontend to the ZPublisher. The big solution would be to replace ZPublisher with zope.publisher and a custom Zope2-oriented publication + appropriate traversers. In this case I wouldn't advise for adapting the Zope 3 request to a Zope 2 request. I would rather introduce a new request type, IZope2Request, based on zope.publisher's IBrowserRequest, that provides all the additional Zope 2 API. I think the big solution would take a considerable effort. It's less than three weeks before feature freeze. That is very little time even for the small solution. Big or small? Would this be an optional and configurable feature or replacement of the current infrastructure? Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgpe6PAKRkeFX.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: z3 server+publication refactor for z2
Philipp von Weitershausen wrote: I think the big solution would take a considerable effort. It's less than three weeks before feature freeze. That is very little time even for the small solution. Actually, I *think* I was wrong. The feature freeze will be June 1st, not May 1st. Perhaps the release manager can clear that up? Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: z3 server+publication refactor for z2
From: Andreas Jung [EMAIL PROTECTED] To: Philipp von Weitershausen [EMAIL PROTECTED], Sidnei da Silva [EMAIL PROTECTED], Andreas Jung [EMAIL PROTECTED], Florent Guillaume [EMAIL PROTECTED] cc: List Zope-dev zope-dev@zope.org Subject: Re: z3 server+publication refactor for z2 Date-Sent: 13. April 2006 15:56:17 --On 13. April 2006 15:53:33 +0200 Philipp von Weitershausen [EMAIL PROTECTED] wrote: Philipp von Weitershausen wrote: I think the big solution would take a considerable effort. It's less than three weeks before feature freeze. That is very little time even for the small solution. Actually, I *think* I was wrong. The feature freeze will be June 1st, not May 1st. Perhaps the release manager can clear that up? Bad question :-) I thought for this yr: 1.7 and 1.12 for the releases (freeze one month earlier) and starting next yr: 1.6 and 1.12...but can find find Jim's posting anymore. -aj pgpOy7lSAVqU4.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: z3 server+publication refactor for z2
--On 13. April 2006 15:58:44 +0200 Philipp von Weitershausen [EMAIL PROTECTED] wrote: I think the big solution would take a considerable effort. It's less than three weeks before feature freeze. That is very little time even for the small solution. Big or small? Would this be an optional and configurable feature or replacement of the current infrastructure? I think it'd be technically possible to have both solutions coexist. After all, that's what we're doing in Zope 3. zope.app.twisted and zope.app.server can coexist easily, I don't see why it shouldn't be possible in Zope 2. They must coexist in any case. We can not get rid or replace a major component - neither without breaking compatibility nor without deprecation. -aj -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgpuHLbQm0kve.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: z3 server+publication refactor for z2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: Hi, Sidnei has been working on the Zope 2 publication-refactor branch where he's allowed the use of the Zope 3 Twisted-based server, and of a Zope 3 based publication process. I'd like to see this merge branched in Zope 2 trunk because I'd like Zope 2.10 to be Twisted-based. What's missing from the branch preventing this? What problems have been encountered? - -1 to using Twisted by default in 2.10 -- it is still much slower than ZServer, AFAIK. I don't think we have time to land this and get it tested before 2.10, frankely, although I wouldn't mind it, assuming that one had to explicitly configure the server to use Twisted. (This query is a reaction to my diving in to current asyncore+medusa +ThreadedAsync+PubCore that gives me nightmares when I realize I'll have to implement new server types or new stuff more akin to the ZEO storage server.) Thanks, Florent PS: what do people think of changing ZEO so that it integrates with Twisted properly instead of relying on a private event loop hack [please move to zodb-dev if you answer this] Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPnB9+gerLs4ltQ4RAjgfAJ9nPGp87OdimICcrnnOkRUX+0ueRgCg1P5n yNyOReyQQhhXznRpgFYWgbI= =SbAn -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: z3 server+publication refactor for z2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Dorn wrote: On 13.04.2006, at 11:55, Andreas Jung wrote: --On 13. April 2006 11:46:20 +0200 Florent Guillaume [EMAIL PROTECTED] wrote: Hi, Sidnei has been working on the Zope 2 publication-refactor branch where he's allowed the use of the Zope 3 Twisted-based server, and of a Zope 3 based publication process. I'd like to see this merge branched in Zope 2 trunk because I'd like Zope 2.10 to be Twisted-based. What's missing from the branch preventing this? What problems have been encountered? The question is: how complete and stable is this stuff? Does it replace the current implementation or is it an optional feature as in Zope 3.2? twisted is the standard server in zope 3.2 - zserver is optional That is really an accident: it is still in experimental status, and is known to have a *big* performance loss compared to ZServer. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPnC6+gerLs4ltQ4RAscoAJ9XikAbVs8VnG607zEgN2gLrBXXowCgye40 4XOHEXBeGlTGvFicMxRXXpE= =rPsA -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: z3 server+publication refactor for z2
--On 13. April 2006 11:38:38 -0400 Tres Seaver [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: Hi, Sidnei has been working on the Zope 2 publication-refactor branch where he's allowed the use of the Zope 3 Twisted-based server, and of a Zope 3 based publication process. I'd like to see this merge branched in Zope 2 trunk because I'd like Zope 2.10 to be Twisted-based. What's missing from the branch preventing this? What problems have been encountered? - -1 to using Twisted by default in 2.10 -- it is still much slower than ZServer, AFAIK. I don't think we have time to land this and get it tested before 2.10, frankely, although I wouldn't mind it, assuming that one had to explicitly configure the server to use Twisted. Twisted as default really is not acceptable. If it is stable and does not inter with the rest of Zope we could include but it really depends on the stability and compatibility. Including it just for the sake having it in is not acceptable. -aj -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgp1wThnLyVUS.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] 64-bit BTrees
I have a need for 64-bit BTrees (at least for IOBTree and OIBTree), and I'm not the first. I've created a feature development branch for this, and checked in my initial implementation. I've modified the existing code to use PY_LONG_LONG instead of int for the key and/or value type; there's no longer a 32-bit version in the modified code. Any Python int or long that can fit in 64 bits is accepted; ValueError is raised for values that require 65 bits (or more). Keys and values that can be reported as Python ints are, and longs are only returned when the value cannot be converted to a Python int. This can have a substantial effect on memory consumption, since keys and/or values now take twice the space. There may be performance issues as well, but those have not been tested. There are new unit tests, but more are likely needed. If you're interested in getting the code from Subversion, it's available at: svn://svn.zope.org/repos/main/ZODB/branches/fdrake-64bits/ Ideally, this or some variation on this could be folded back into the main development for ZODB. If this is objectionable, making 64-bit btrees available would require introducing new versions of the btrees (possibly named LLBTree, LOBTree, and OLBTree). I welcome comments. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Don't let schooling interfere with your education. -- Mark Twain ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: 64-bit BTrees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: I have a need for 64-bit BTrees (at least for IOBTree and OIBTree), and I'm not the first. I've created a feature development branch for this, and checked in my initial implementation. I've modified the existing code to use PY_LONG_LONG instead of int for the key and/or value type; there's no longer a 32-bit version in the modified code. Any Python int or long that can fit in 64 bits is accepted; ValueError is raised for values that require 65 bits (or more). Keys and values that can be reported as Python ints are, and longs are only returned when the value cannot be converted to a Python int. This can have a substantial effect on memory consumption, since keys and/or values now take twice the space. There may be performance issues as well, but those have not been tested. There are new unit tests, but more are likely needed. If you're interested in getting the code from Subversion, it's available at: svn://svn.zope.org/repos/main/ZODB/branches/fdrake-64bits/ Ideally, this or some variation on this could be folded back into the main development for ZODB. If this is objectionable, making 64-bit btrees available would require introducing new versions of the btrees (possibly named LLBTree, LOBTree, and OLBTree). I think coming up with new types is the only reasonable thing to do, given the prevalence of persistent BTrees out in the wild. Changing the runtime behavior (footprint, performance) of those objects is probably not something which most users are going to want, at least not without carefully considering the implications. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPpyu+gerLs4ltQ4RAmh1AJ9/dLigNMrQgIFNASKWbpvboapywwCePV22 /3d8kFGTjipAVCsy5fnuLa4= =xe6v -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: 64-bit BTrees
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: I have a need for 64-bit BTrees (at least for IOBTree and OIBTree), and I'm not the first. I've created a feature development branch for this, and checked in my initial implementation. I've modified the existing code to use PY_LONG_LONG instead of int for the key and/or value type; there's no longer a 32-bit version in the modified code. Any Python int or long that can fit in 64 bits is accepted; ValueError is raised for values that require 65 bits (or more). Keys and values that can be reported as Python ints are, and longs are only returned when the value cannot be converted to a Python int. This can have a substantial effect on memory consumption, since keys and/or values now take twice the space. There may be performance issues as well, but those have not been tested. There are new unit tests, but more are likely needed. If you're interested in getting the code from Subversion, it's available at: svn://svn.zope.org/repos/main/ZODB/branches/fdrake-64bits/ Ideally, this or some variation on this could be folded back into the main development for ZODB. If this is objectionable, making 64-bit btrees available would require introducing new versions of the btrees (possibly named LLBTree, LOBTree, and OLBTree). I think coming up with new types is the only reasonable thing to do, given the prevalence of persistent BTrees out in the wild. Changing the runtime behavior (footprint, performance) of those objects is probably not something which most users are going to want, at least not without carefully considering the implications. It really depends on what the impact is. It would be nice to get a feel for whether this really impacts memory or performance for real applications. This adds 4-bytes per key or value. That isn't much, especially in a typical Zope application. Similarly, it's hard to say what the difference in C integer operations will be. I can easily imagine it being negligible (or being significant :). OTOH, adding a new type could be a huge PITA. We'd like to use these with existing catalog and index code, all of which uses IIBTrees. If the performance impacts are modest, I'd much rather declare IIBTrees to use 64-bit rather than 32-bit integers. I suppose an alternative would be to add a mechanism to configure IIBTrees to use either 32-bit or 64-bit integers at run-time. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: 64-bit BTrees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: I have a need for 64-bit BTrees (at least for IOBTree and OIBTree), and I'm not the first. I've created a feature development branch for this, and checked in my initial implementation. I've modified the existing code to use PY_LONG_LONG instead of int for the key and/or value type; there's no longer a 32-bit version in the modified code. Any Python int or long that can fit in 64 bits is accepted; ValueError is raised for values that require 65 bits (or more). Keys and values that can be reported as Python ints are, and longs are only returned when the value cannot be converted to a Python int. This can have a substantial effect on memory consumption, since keys and/or values now take twice the space. There may be performance issues as well, but those have not been tested. There are new unit tests, but more are likely needed. If you're interested in getting the code from Subversion, it's available at: svn://svn.zope.org/repos/main/ZODB/branches/fdrake-64bits/ Ideally, this or some variation on this could be folded back into the main development for ZODB. If this is objectionable, making 64-bit btrees available would require introducing new versions of the btrees (possibly named LLBTree, LOBTree, and OLBTree). I think coming up with new types is the only reasonable thing to do, given the prevalence of persistent BTrees out in the wild. Changing the runtime behavior (footprint, performance) of those objects is probably not something which most users are going to want, at least not without carefully considering the implications. It really depends on what the impact is. It would be nice to get a feel for whether this really impacts memory or performance for real applications. This adds 4-bytes per key or value. That isn't much, especially in a typical Zope application. Similarly, it's hard to say what the difference in C integer operations will be. I can easily imagine it being negligible (or being significant :). OTOH, adding a new type could be a huge PITA. We'd like to use these with existing catalog and index code, all of which uses IIBTrees. If the performance impacts are modest, I'd much rather declare IIBTrees to use 64-bit rather than 32-bit integers. I suppose an alternative would be to add a mechanism to configure IIBTrees to use either 32-bit or 64-bit integers at run-time. Who uses IOBTree / OIBTree / IIBTree? - Catalogs map RIDs to UIDs as IOBTrees (one record per indexed object) - Most indexes (those derived from Unindex) map RID to indexed value as an IOBTree (one record per object with a value meaningful to that index) and map values to RIDs as OOBTrees (where the second O is usually an IITreeSet). - ZCTextIndex uses IIBTrees to map word IDs to RIDs, in various ways, and make use of IOBTrees as wel.. - Relationship indexes (typically not stored within catalogs) usually have an IIBTree which is the mapping of the edges as pairs of internal node IDs (one per explicit relationship), with OIBTrees to map the user-supplied node value to a node ID. I would guess that if you could do a census of all the OIDs in all the Datas.fs in the world, a significant majority of them would be instances of classes declared in IOBTree / IIBTree (certainly the bulk of *transaction* records are going to be tied up with them). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPtfe+gerLs4ltQ4RAkDoAJ9998Bj5yMqVpKoQOn/s3Hf5GZkBwCcC4uY kXTqmBsu6vMYx4fzAOWF5uo= =yVVq -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: 64-bit BTrees
[Tres Seaver] ... I would guess that if you could do a census of all the OIDs in all the Datas.fs in the world, a significant majority of them would be instances of classes declared in IOBTree / IIBTree (certainly the bulk of *transaction* records are going to be tied up with them). Provided it still works, people can use ZODB's analyze.py to figure that out. But supposing I flavors of BTrees are the only objects that exist, what follows from that? It's not clear. I can guarantee that multiunion() will run slower, because its workhorse radix sort will need 8 (instead of 4) passes. Beyond that, it requires someone to try it. I'm reminded that when the MEMS Exchange wrote Durus (a kind of ZODB lite ;-): http://www.mems-exchange.org/software/durus/ ) they left their entire BTree implementation coded in Python -- it was fast enough that way. The difference between ZODB's BTree C code pushing 4 or 8 bytes around at a time may well be insignificant overall. If done carefully, pickle sizes probably won't change: cPickle has a large number of ways to pickle integers, and picks the smallest one needed to hold an integer's actual value. Provided the internal getstate() functions are careful to avoid Python longs when possible, bigger pickles won't happen unless more than 32 bits are actually needed to hold an integer. There's also that ZODB's current I trees are badly broken on 64-bit boxes (except for Win64) in at least this way: http://collector.zope.org/Zope/1592 That problem would go away by magic. looks-like-a-case-of-measure-twice-cut-once-ly y'rs - tim ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
