Last modified: 2008-04-28 09:53:03 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 13858 - performance: SMWSQLStore->getPropertyTable() always loops 10 times even if no subproperties
performance: SMWSQLStore->getPropertyTable() always loops 10 times even if no...
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: 2008-04-27 06:16 UTC by S Page
Modified: 2008-04-28 09:53 UTC (History)
0 users

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


Attachments

Description S Page 2008-04-27 06:16:59 UTC
I enable profiling, and noticed in the log 10 sets of 

SQL: INSERT /* SMW::getPropertyTable 127.0.0.1 */ INTO smw_res (title) SELECT `smw_subprops`.subject_title
                FROM `smw_subprops`,smw_new WHERE
                `smw_subprops`.object_title=smw_new.title

in the log for every query of a property, even when the property has no subproperties.

If you look at SMW_SQLStore.php's getPropertyTable(), the $i<$smwgQSubpropertyDepth loop has two

	if ($db->affectedRows() == 0) { // no change, exit loop
		continue;

but PHP's "continue" *doesn't* exit the loop, the doc says "skip the rest of the current loop iteration and continue execution at the condition evaluation".

I don't understand the second INSERT IGNORE, but I think somewhere the code can truly exit the loop using PHP's "break".  Getting rid of 9 INSERT WHERE's might help performance.

(It might also be worth restructuring the code to avoid creating one or both of the temporary tables until needed.)

I think there might be a similar glitch in getCategoryTable().  It has different code structure, it does the two INSERTs in a row.
Comment 1 Markus Krötzsch 2008-04-28 09:53:03 UTC
Oops, indeed! The same issue occurred in the category-materialisation above. Fixed in SVN now.

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


Navigation
Links