Re: [Zope-dev] Proxy Object / __getattr__ / Acquisition
At 14:28 2002-08-29 -0700, [EMAIL PROTECTED] said:
>I am trying to implement a proxy class (specifically for the purposes of
>multi-versioned document objects (folderish proxies that contain the object
Hi Sean,
We've been "stealing" some code from CMFCore.Skinnable to
do similar things (multi-language objects):
Skinnable gets the skins when the objects is being wrapped (e.g.
in the objects __of__ method) and overrides __getattr__ which
uses the skins or falls back to an unbound superGetAttr method
that points to the inherited __getattr__.
(The superGetAttr have pussled us because it seams like superGetAttr is None,
but everything still work as expected.)
We replace the skin with a VeryTinyDataWrapper which (of course) implements
Acquisition.Implicit.
Would this work better that the way your doing it?
We currently implementing this so I don't know for sure that it
is faster, but it's from CMF (a key part to) so it shouldn't be to slow or?
def setupCurrentLanguageData(self):
#the request part is a rest from Skinnable, I don't think it can
be removed.
request=self.request
#replace this with anything that returns
lang_code=self.EasyLanguageService.getCurrentLanguage()
ob = self._current_language.get(lang_code, VerySmallData())
self._v_c_language = (request, ob, {})
def __getattr__(self, name, marker=None):
# OK, see if we can find the language service:
if not name.startswith('_') and not name.startswith('aq_'):
cl = self._v_c_language
if cl is not None:
request, ob, ignore = cl
if not ignore.has_key(name):
subob = getattr(ob, name, _marker)
if subob is not _marker:
# Return it in context of self, forgetting
# its location and acting as if it were located
# in self.
return aq_base(subob)
else:
ignore[name] = 1
if superGetAttr is None:
raise AttributeError, name
return superGetAttr(self, name)
def __of__(self, parent):
'''
Sneakily sets up the current language then returns the wrapper
that Acquisition.Implicit.__of__() would return.
'''
w_self = ImplicitAcquisitionWrapper(aq_base(self), parent)
try:
w_self.setupCurrentLanguageData()
except:
# This shouldn't happen, even if the requested current language
# does not exist.
import sys
from zLOG import LOG, ERROR
LOG('CMFCore', ERROR, 'Unable to setupCurrentLanguageData()',
error=sys.exc_info())
return w_self
Regards,
Johan Carlsson
--
Torped Strategi och Kommunikation AB
Johan Carlsson
[EMAIL PROTECTED]
Mail:
Birkagatan 9
SE-113 36 Stockholm
Sweden
Visit:
Västmannagatan 67, Stockholm, Sweden
Phone +46-(0)8-32 31 23
Fax +46-(0)8-32 31 83
Mobil +46-(0)70-558 25 24
http://www.torped.se
http://www.easypublisher.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Site-crawler (find unused objects)
Hi, has anyone written a script which crawls a site and lists all objects which aren't referenced anymore? Tobias Herp Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das un- erlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proxy Object / __getattr__ / Acquisition
[EMAIL PROTECTED] wrote: > I am trying to implement a proxy class (specifically for the purposes of > multi-versioned document objects (folderish proxies that contain the object > that they proxy to). I am using __getattr__ within my product, and the code > pasted below works, and does not "break" Implicit acquisition (because the > object that _CurrentVersion points to is subclassed from SimpleItem, which > implements Implicit Acquisition). However, because of the way that this > messes with Acquisition, certain things like accessing the ZMI pages or > acquired methods can be quite slow (but work). I suspect that this is > because an instance of this class actually acquires items through the item > it proxies to, which conveniently is contained inside it, which makes > acquisition work for the instance of this class (albeit magnitudes slower). > > I would really like to make this perform better and act properly, but I'm at > a loss as to the right way to do this. Thoughts? > > Sean > > class MVProxy(Folder): > """ > Object acting as proxy to multiple document > implementations serving for each version of this > document; this is a proxy object class > Subclasses OFS.Folder.Folder > """ > def __init__(self, id, title=''): > self.id = id > self.title = title > timestamp = str(int(time.mktime(time.localtime( > currentId = id+'_'+timestamp > current = DocumentCoreImpl(currentId, title) > self._setObject(currentId, current) > self._CurrentVersion = current > > def __getattr__(self, name): > return getattr(self._CurrentVersion, name) Can you use __bobo_traverse__ instead of __getattr__ ? That should make things much faster. -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Proxy Object / __getattr__ / Acquisition
I am trying to implement a proxy class (specifically for the purposes of multi-versioned document objects (folderish proxies that contain the object that they proxy to). I am using __getattr__ within my product, and the code pasted below works, and does not "break" Implicit acquisition (because the object that _CurrentVersion points to is subclassed from SimpleItem, which implements Implicit Acquisition). However, because of the way that this messes with Acquisition, certain things like accessing the ZMI pages or acquired methods can be quite slow (but work). I suspect that this is because an instance of this class actually acquires items through the item it proxies to, which conveniently is contained inside it, which makes acquisition work for the instance of this class (albeit magnitudes slower). I would really like to make this perform better and act properly, but I'm at a loss as to the right way to do this. Thoughts? Sean class MVProxy(Folder): """ Object acting as proxy to multiple document implementations serving for each version of this document; this is a proxy object class Subclasses OFS.Folder.Folder """ def __init__(self, id, title=''): self.id = id self.title = title timestamp = str(int(time.mktime(time.localtime( currentId = id+'_'+timestamp current = DocumentCoreImpl(currentId, title) self._setObject(currentId, current) self._CurrentVersion = current def __getattr__(self, name): return getattr(self._CurrentVersion, name) +--- | Sean Upton | Site Technology Supervisor SignOnSanDiego.com | Development & Integration The San Diego Union-Tribune | 619.718.5241 [EMAIL PROTECTED] |PATH_TO_THE_DARK_SIDE = 'c:\winnt\system32' +--- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope-Annce] ZEO 2.0 beta 1 released
> "TD" == Toby Dickenson <[EMAIL PROTECTED]> writes: TD> There is an O(n) option with easy logic... fragment big strings TD> inside message_output. Sounds like a possibility. It would still be nice to have something in handle_write() to avoid extra slicing on partial send()s. But your patch is nice and simple. Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Acquisition and method lookup: loosing acquisition context
Acquisition lookup for (ExtensionClass'es Python) methods is not done
through the standard "__of__" call but handled specially:
if (PyECMethod_Check(r) && PyECMethod_Self(r)==self->obj)
ASSIGN(r,PyECMethod_New(r,OBJECT(self)));
As a consequence, the method's "im_self" is not fully acquisition wrapped.
Rather, the context is more or less stripped down.
I would find it more naturally, when (ExtensionClass'es Python)
methods conceptually had an "__of__" method that relays the context
to "im_self". The code above would then become:
if (PyECMethod_Check(r)) {
im_self= PyECMethod_Self(r);
if (has__of__(im_self)):
ASSIGN(r,PyECMethod_New(r,__of__(im_self,OBJECT(self;
}
This could be optimized to:
if (PyECMethod_Check(r)) {
im_self= PyECMethod_Self(r);
if (im_self==self->obj)
ASSIGN(r,PyECMethod_New(r,OBJECT(self)));
else if (has__of__(im_self)):
ASSIGN(r,PyECMethod_New(r,__of__(im_self,OBJECT(self;
}
But maybe, there is a reason for the special rule.
I am unhappy with the special method treatment because
my "References" product does not work as expected due to the leaking context.
Most applications using "getattr" to look up methods in other objects
will suffer from the same problem.
Dieter
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unit testing on win32 with FAT requires patch tocustom_zodb.py,is this a known issue?
On Thu, 29 Aug 2002, Chris Withers wrote:
> Shane Hathaway wrote:
> >
> > No, this is not a known issue. Could you provide a traceback?
>
> Traceback (most recent call last):
>File "testStripogram.py", line 103, in ?
> import Zope
>File "D:\ZOPE\25228D~1.1\lib\python\Zope\__init__.py", line 40, in ?
> m=imp.load_module('Zope.custom_zodb', m[0], m[1], m[2])
>File "D:\ZOPE\25228D~1.1\lib\python\Testing\custom_zodb.py", line 7, in ?
> Storage = DemoStorage(base=FileStorage(dfi, read_only=1), quota=(1<<20))
>File "D:\ZOPE\25228D~1.1\lib\python\ZODB\FileStorage.py", line 200, in __init_
> _
> raise ValueError, "can\'t create a read-only file"
> ValueError: can't create a read-only file
Apparently the file "Data.fs.in" doesn't exist. Why? (Try adding "print
dfi" to custom_zodb.py.)
Shane
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unit testing on win32 with FAT requires patch to custom_zodb.py,isthis a known issue?
Shane Hathaway wrote:
>
> No, this is not a known issue. Could you provide a traceback?
Traceback (most recent call last):
File "testStripogram.py", line 103, in ?
import Zope
File "D:\ZOPE\25228D~1.1\lib\python\Zope\__init__.py", line 40, in ?
m=imp.load_module('Zope.custom_zodb', m[0], m[1], m[2])
File "D:\ZOPE\25228D~1.1\lib\python\Testing\custom_zodb.py", line 7, in ?
Storage = DemoStorage(base=FileStorage(dfi, read_only=1), quota=(1<<20))
File "D:\ZOPE\25228D~1.1\lib\python\ZODB\FileStorage.py", line 200, in __init_
_
raise ValueError, "can\'t create a read-only file"
ValueError: can't create a read-only file
cheers,
Chris
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Windows Zope Install
> The WISE install script is in the /inst directory of the > releases. Thanks got it. No wonder I couldn't find it in CVS. -- Andy McKay Agmweb Consulting http://www.agmweb.ca ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]
On Thursday 29 Aug 2002 2:21 pm, Oliver Bleutgen wrote: > If something like I described would be implemented into zope, it surely > should be possible to start an extra thread for doing the stuff you give > as an example The issue is that zope *already* runs *every* request in a seperate thread from the one that handles the connections, and has done since version 2.0. In most almost every case these worker threads will have finished their per-request work and all response data will have been calculated before the user has a chance to press the stop button. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Windows Zope Install
> Can anyone point me to the location of the configuration file for the > Windows install in CVS? I'm sure Brian pointed it out to me once, > but I cant > find it at the moment... > -- > Andy McKay Hi Andy - The WISE install script is in the /inst directory of the releases. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]
Christopher N. Deckard wrote: > Oh, and back on the original topic, does anyone know for sure if > the browsers actually send something to the server when "stop" is > pressed? Yes, it sends a "RST" packet. It ends the tcp-connection. That's why I think throwing an exception when something tries to output data to be served to such a connection is the right thing to do (while it may be not so easy to implement with zope, I don't know). Since the connection is gone, there's no point in accumulating data to be sent back. Tim Hoffman <[EMAIL PROTECTED]> wrote: > Hi > > > Just my 2c worth, > > I wouldn't want this to be a blanket approach if it where ever > implemented. > > If my ZODB is so big that it takes half an hour to rebuild, I would hate > it to be aborted just because the browser lost it's connection (ie IE > crashed ;-) > > or running a big import. I don't need the browser to hang around for the > end result, I just want it to complete at some point. (ie kicking off > long running processes through xml-rpc, I don't want to keep the > connection open for the duration.) I don't know why these examples should be an argument against implementing a saner (just IMO!) policy into zope regarding connection resets. If something like I described would be implemented into zope, it surely should be possible to start an extra thread for doing the stuff you give as an example, or - less desireable IMO - to ignore the connection reset. If this were implemented with an exeption, you just had to catch it and you're done. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZMI: preserve the sort criteria
I often sort the object list in the ZMI by modification date, to get the script on top I'm currently working on. However, whenever I navigate to another folder, the default sorting is by name. I'd like it very much if the sort criteria would be kept until changed explicitly, e. g. by storing it in the SESSION. Cheers, Tobias Herp Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das un- erlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]
On Thu, 29 Aug 2002 11:41:44 +0100, Chris Withers spoke forth: > Original Message > Subject: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs > Date: 29 Aug 2002 14:36:30 +0800 > From: Tim Hoffman <[EMAIL PROTECTED]> > > If my ZODB is so big that it takes half an hour to rebuild, I > would hate it to be aborted just because the browser lost it's > connection (ie IE crashed ;-) > > or running a big import. I don't need the browser to hang around > for the end result, I just want it to complete at some point. (ie > kicking off long running processes through xml-rpc, I don't want > to keep the connection open for the duration.) This brings up a question I've always had, is it possible to "fork" a request into the background. Your example being an import, is it possible to set up the import script to do the following: * User requests that some import file be imported * Zope makes sure it's a valid import file (extension or whatever it does, basically that it exists) * Zope forks the import off into the background * Zope responds to the request saying "The import is in progress, blahdy blahdy blah." Meanwhile, the user gets instant feedback that his import is going, and doesn't have to wait for the browser to say anything, or time out, whichever comes first. I think this would be very useful if one were writing something like an order processing system, where you wanted to build the order processing into Zope. Someone adds junk to their "shopping cart", clicks the "send me my junk" button, and gets instant feedback telling him that the order is being processed. I can think of lots of uses for that kind of thing. Oh, and back on the original topic, does anyone know for sure if the browsers actually send something to the server when "stop" is pressed? > Either you can programatically look at the state of the connection > (within the process and chose to kill it) or there was a console > tool so that you could see long running threads and kill them. A console tool for managing threads would be great. Being able to kill off a request, like one of our users hitting the undo or history tab, would be nice, until we get a patch going for that. Some things just take way too long. -Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]
I think Tim meant this to go to the list ;-) Chris Original Message Subject: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs Date: 29 Aug 2002 14:36:30 +0800 From: Tim Hoffman <[EMAIL PROTECTED]> To: Chris Withers <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <001b01c24aea$6fa37060$6717a8c0@dorothy> <[EMAIL PROTECTED]> <1030196732.1365.34.camel@james> <[EMAIL PROTECTED]> <1030216329.1327.114.camel@james> <[EMAIL PROTECTED]> Hi Just my 2c worth, I wouldn't want this to be a blanket approach if it where ever implemented. If my ZODB is so big that it takes half an hour to rebuild, I would hate it to be aborted just because the browser lost it's connection (ie IE crashed ;-) or running a big import. I don't need the browser to hang around for the end result, I just want it to complete at some point. (ie kicking off long running processes through xml-rpc, I don't want to keep the connection open for the duration.) Either you can programatically look at the state of the connection (within the process and chose to kill it) or there was a console tool so that you could see long running threads and kill them. Rgds Tim On Wed, 2002-08-28 at 19:49, Chris Withers wrote: > I know I'm late in on this thread, but I thought I'd throw in my views. > > I'd like to see the REQUEST be flat plain aborted when someone hits the stop > button or the connection dies. > > I don't is the is context.REQUEST.RESPONSE.isClientConnected() really working. > How would I plug this in an expensive SQL SELECT/JOIN? Why do we need this extra > programming overhead? > > As for the long running administrative tasks, I actually see the ability to > bugger off and leave them running as an extremely bad thing. Say I hit 'pack' on > a big fat ZODB. I then go somewhere else. How do I now tell when its done? The > only was would be to go and look at 'top' and guess which python thread is doing > the pack and wait till its CPU usage drops to zero. That's pretty ropey ;-) > For the same reason, I hate ZEO's pack's possibility of returning before a pack > is finished. > > If you do a pack, I really think you should wait for the browser to return. If > the browser times out, then use something like wget. If I hit 'stop', the pack > should abort. > > As a parting example, what happens if I accidentally start a pack? How can I > stop it? ;-) > > cheers, > > Chris > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Slow zope on windows 2000?
On Wednesday 28 Aug 2002 6:46 pm, Casey Duncan wrote: > One other difference is classically due to a more efficient select > mechanism on Unix than Windows (ala asyncore), making multitasking more > efficient on *nix. However, I don't know if that's true anymore post-NT4. Yes, thats still true. select is the native Unix way of handling asynchronous IO, but on Win32 select is a compatability layer provided for posix compatability, and to make it easy to port unix network services to windows. Win32's native concurrency and asynchronous IO capabilities are in many ways superior to the posix select. They are top of my list of things I regret leaving behind since moving my recent development from windows to linux. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope-Annce] ZEO 2.0 beta 1 released
On Wednesday 28 Aug 2002 2:19 pm, Jeremy Hylton wrote:
> I'd like to change this bit of code in handle_write():
>
> if n < len(v):
> # XXX It's unfortunate that we end up making many
> # slices of a large string.
> output.insert(0, v[n:])
> break # we can't write any more
>
> If we send a very large message, which could be caused by a big pickle
> or just a transaction that touches a lot of objects, the message gets
> sent in little chunks. The current implementation uses string slicing
> to save the rest of the string, but that ends up making many copies of
> the large string -- an O(n^2) proposition.
>
> A possible solution is to store an index into the first string in
> __output and just increment the index. The logic will be a bit tricky
> to get right.
There is an O(n) option with easy logic... fragment big strings inside
message_output.
diff attached.
[hmmm. Its use of a python list as a fifo queue is O(n2) worst case, but I
doubt we will be affected by that in practice]
Index: smac.py
===
RCS file: /cvs-repository/Packages/ZEO/smac.py,v
retrieving revision 1.19
diff -c -4 -r1.19 smac.py
*** smac.py 22 Aug 2002 18:29:13 - 1.19
--- smac.py 29 Aug 2002 09:40:44 -
***
*** 133,140
--- 133,145
return 0
else:
return 1
+ # We chose 6 as the socket limit by looking at the
+ # largest strings that we could pass to send() without
+ # blocking.
+ _write_chunk_size = 6
+
def handle_write(self):
output = self.__output
while output:
# Accumulate output into a single string so that we avoid
***
*** 144,159
# unfortunate interaction between the Nagle algorithm and
# delayed acks. If we send a very large string, only a
# portion of it will actually be delivered at a time.
- # We chose 6 as the socket limit by looking at the
- # largest strings that we could pass to send() without
- # blocking.
-
l = 0
for i in range(len(output)):
l += len(output[i])
! if l > 6:
break
i += 1
# It is very unlikely that i will be 1.
--- 149,160
# unfortunate interaction between the Nagle algorithm and
# delayed acks. If we send a very large string, only a
# portion of it will actually be delivered at a time.
l = 0
for i in range(len(output)):
l += len(output[i])
! if l >= self._write_chunk_size:
break
i += 1
# It is very unlikely that i will be 1.
***
*** 189,198
"This action is temporarily unavailable."
""
)
# do two separate appends to avoid copying the message string
! self.__output.append(struct.pack(">i", len(message)))
! self.__output.append(message)
def close(self):
if self.__closed is None:
self.__closed = 1
--- 190,206
"This action is temporarily unavailable."
""
)
# do two separate appends to avoid copying the message string
! l = len(message)
! self.__output.append(struct.pack(">i", l))
! if l <= self._write_chunk_size:
! self.__output.append(message)
! else:
! # fragment large strings now, to avoid O(n2) behavior when
! # dealing with huge strings.
! for start in range(0,l,self._write_chunk_size):
! self.__output.append(message[start:start+self._write_chunk_size])
def close(self):
if self.__closed is None:
self.__closed = 1
Re: [Zope-dev] Slow zope on windows 2000?
Hello Casey, > One thing to remember is that running multi-treaded Python apps on a > multi-processor box is suboptimal unless you can bind all the threads to a > single processor, due to the Python GIL. IOW : Buying a dual processor computer is not so usefull if the computer is dedicated running zope? And if you have to use a dual CPU computer, binding all the threads to a single processor increases zope performance? (If so, how can you do that? :) > The only way to do a true comparison would be to run the same tests on the > same app on the same hardware with the same load but with different OSes. That's true. I was wondering if you guys at zope comp. have any recent benchmarks yourself with the different Operating systems? Martijn. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
