Repeated calls to extractNameValuePair inefficient
TWiki calls
extractNameValuePair repeatedly to extract parameters from
TWikiVariables. A new
extractParameters function that has been added to
CairoRelease which does the same parsing as
extractNameValuePair and returns a hash containing all name/value pairs. This is much more efficient.
extractNameValuePair related
PerformanceImprovementsInDakar:
--
PeterThoeny - 21 Oct 2004
Having an alternative to extractNameValuePair would make sense. When extracting one or two values it makes sense, but when there's more than a dozen (eg SEARCH) this becomes inefficient. This is more of an issue when (for example) you start using
NamedIncludeSections to provide end-user themeable skins by including sections for off a furniture page.
Parsing the parameters once rather than 21 times (in the case of SEARCH) and extracting from a hash would make a lot more sense.
Source to be parsed:
- sourceline := "? itemvalue "? (' ' attributedefinition)*
attributedefinition := attribute = attributevalue
attribute := [a-zA-Z0-9][a-zA-Z_0-9]*
attributevalue := "[^"]+"
Function call:
extractNameValueHash($args)
Result :=
- %result st: { attributes in source } is subset of { keys %hash }
%result{"_"} := itemvalue
Use a gobbling approach:
- chop off the itemvalue
- repeatedly chop of key-value pairs
- Build hash as you go along
Return hash.
- Crap function name - non-crap name welcome.
- Memoise the result?
- Objectify this using autoload? (Probably adds unnecessary overhead given objects not most efficient thing in perl)
- Modify user created hash instead? (ie pass a reference the hash for modifcation ala ruby's ! methods, or normal approach in languages like python)
- Less perlesque to do this. (Fairly perl 6-ish though)
Functions that would benefit:
|
|
| Function |
Number of calls to extractNameValuePair |
Candidate for benefits |
| handleIncludeFile |
4 |
Y |
| handleMetaSearch |
4 |
Y |
| handleSearchWeb |
21 |
Y |
| handleTime |
1 |
- |
| handleToc |
3 |
Y |
| handleWebAndTopicList |
7 |
Y |
| handleUrlParam |
2 |
Y |
| handleUrlEncode |
1 |
- |
| handleTmplP |
1 |
- |
| renderParent |
5 |
Y |
| getFormField |
6 |
Y |
| renderMetaData |
1 |
- |
| prvHandleWebVariable |
2 |
Y |
| handleCalendar |
5 |
Y |
| handleComment |
5 |
Y |
| handleCityTime |
1 |
- |
| handleTopicList |
4 |
Y |
| handlePollResults |
7 |
Y |
| handlePollVoters |
4 |
Y |
| handleRandomPage |
3 |
Y |
| doCalc |
1 |
- |
| handleDrawing |
1 |
- |
| - |
Total Number Benefitting |
15 |
| - |
Number of parses |
75 |
| - |
Number of subs calling (Also maximum required parses) |
22 |
| - |
Number of 'un-necessary' parses |
53 |
|
|
|
(This list includes a small number of plugins* - but running with a small number of plugins is not unusual)
-
- (*) CalendarPlugin, CommentPlugin, LocalCityTimePlugin, PollPlugin, SpreadSheetPlugin, RandomTopicPlugin, TWikiDrawPlugin)
I don't pretend this will have a huge impact, but it will help with cleanup of the code, and makes migrating from positional parameters and globals to a more objectified setup easier (and hence easier to extend, maintain and regression test).
--
TWikiGuest- 28 Aug 2003
I've got something in the offing that will take care of this, and is quite a bit more ambitious. I'm going to commit it as soon as we get our version control scheme switched over to Subversion.
--
WalterMundt - 11 May 2004
Why don't you just use TWiki::Contrib::Attrs from the
AttrsContrib repository, and pass the Attrs object around?
--
CrawfordCurrie - 12 May 2004
TWiki::Contrib::Attrs parsing algorythm is different from
extractNameValuePair and would introduce incompatibilities with existing
TWikiApplications. The
extractParameters function that has been added to
CairoRelease does the same parsing as
extractNameValuePair and returns a hash.
--
PeterThoeny - 21 Oct 2004