You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2006/09/11 12:17:22 UTC

[jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency

    [ http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12433818 ] 
            
Graham Dumpleton commented on MODPYTHON-93:
-------------------------------------------

Have we decided that we will not try and be compatible with Trac and expect people using mod_python 3.3 to use the next unreleased version of Trac? This next version of Trac works via a WSGI gateway and thus doesn't use FieldStorage and thus doesn't have the problems seen here. Can we mark the original issue as resolved for 3.3?

> Improve util.FieldStorage efficiency
> ------------------------------------
>
>                 Key: MODPYTHON-93
>                 URL: http://issues.apache.org/jira/browse/MODPYTHON-93
>             Project: mod_python
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 3.2.7
>            Reporter: Jim Gallacher
>         Assigned To: Jim Gallacher
>            Priority: Minor
>             Fix For: 3.3
>
>         Attachments: modpython325_util_py_dict.patch
>
>
> Form fields are saved as a list in a FieldStorage class instance. The class implements a __getitem__ method to provide dict-like behaviour.  This method iterates over the complete list for every call to __getitem__. Applications that need to access all the fields when processing the form will show O(n^2) behaviour where n == the number of form fields. This overhead could be avoided by creating a dict (to use as an index) when the FieldStorage instance is created.
> Mike Looijmans has been investigating StringField and Field as well. It is probably reasonable to include information on his work in this issue as well, so that we can consider all of these efficiency issues in toto.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency

Posted by Mike Looijmans <nl...@natlab.research.philips.com>.
As I recall, dropping the current Trac version for 3.3 is what we wanted to do.

In addition, there was talk about implementing a __setitem__ method as well to support manual 
insertion of fields, so that FieldStorage becomes a real dictionary-like object. The add_field 
method was to be reworked so that it could be publicly available.

(side thought: Allowing population from code rather than only from a Request object might allow 
FieldStorage to be used in test code)

--
Mike Looijmans
Philips Natlab / Topic Automation


Graham Dumpleton (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12433818 ] 
>             
> Graham Dumpleton commented on MODPYTHON-93:
> -------------------------------------------
> 
> Have we decided that we will not try and be compatible with Trac and expect people using mod_python 3.3 to use the next unreleased version of Trac? This next version of Trac works via a WSGI gateway and thus doesn't use FieldStorage and thus doesn't have the problems seen here. Can we mark the original issue as resolved for 3.3?
> 
> 
>>Improve util.FieldStorage efficiency
>>------------------------------------
>>
>>                Key: MODPYTHON-93
>>                URL: http://issues.apache.org/jira/browse/MODPYTHON-93
>>            Project: mod_python
>>         Issue Type: Improvement
>>         Components: core
>>   Affects Versions: 3.2.7
>>           Reporter: Jim Gallacher
>>        Assigned To: Jim Gallacher
>>           Priority: Minor
>>            Fix For: 3.3
>>
>>        Attachments: modpython325_util_py_dict.patch
>>
>>
>>Form fields are saved as a list in a FieldStorage class instance. The class implements a __getitem__ method to provide dict-like behaviour.  This method iterates over the complete list for every call to __getitem__. Applications that need to access all the fields when processing the form will show O(n^2) behaviour where n == the number of form fields. This overhead could be avoided by creating a dict (to use as an index) when the FieldStorage instance is created.
>>Mike Looijmans has been investigating StringField and Field as well. It is probably reasonable to include information on his work in this issue as well, so that we can consider all of these efficiency issues in toto.
> 
>