Last modified: 2007-10-12 19:43:06 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8961 - performance: refactor DataType/DataValue to do less work in processValue()
performance: refactor DataType/DataValue to do less work in processValue()
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Markus Krötzsch
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-13 07:11 UTC by S Page
Modified: 2007-10-12 19:43 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description S Page 2007-02-13 07:11:07 UTC
For historical reasons SMWTypeHandler->processValue() (and processXSDValue) does
a lot of work and is a "choke point" for working with attribute values.

This affects performance.  I verified that a simple inline query like
[[Climate:=+]][[Climate:=*] makes a GetSpecialPropertyValues database query for
SERVICE_LINK, because newAttributeValue() winds up calling the datatype's
processValue() which calls addsServiceLinks whether or not they're needed. 

SMWDataValue->setUserValue() and SMWDataType->processValue() need to be
refactored so they do a minimum of work.  Just enough to call back to the
datavalue with setProcessedValues() (and possibly even a subset of those values).

Clients who want additional information from a datavalue like $others
(additional conversions built up by setPrintoutString()) quicksearchLink, and
serviceLinks should explicitly ask for them from the datavalue, which asks its
datatype for them.  As part of this refactoring, there could be a base class for
all datatypes providing a default implementation, which would reduce code size.
Comment 1 Markus Krötzsch 2007-10-12 19:43:06 UTC
This should be fixed now, since all datatype handlers have been replaced by much more lazy datavalue implementations.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links