Topic on Extension talk:RecentPages

Jump to navigation Jump to search
Leucosticte (talkcontribs)

Oh dear, it's doing a separate BedellPenDragon::renderGetBpdProp() for every item, plus it's doing a separate getDisplayTitle() for every item. Not only that, BedellPenDragon::renderRandomPageInCat() does the same thing. Not a big deal, except on templates like ChildWiki:More new articles or ChildWiki:More featured articles. I believe this would be called an O(n) situation. It could get pretty ugly, if the number of articles were to get pretty high.

Probably the most potential for savings is when it's a query that can be done as a LIMIT x (e.g. a new pages feed) or selecting everything in a category, rather than having a WHERE with a bunch of individual pages to select from all over the table (as in the case of random pages). But I'm not sure. I'm no expert on database optimization. Maybe JOINs would make it more efficient; maybe not. Too bad I also know nothing about profiling.

Ugh, I just realized this could get ugly either way, because if I do a join on page_props for the displaytitle and the bpdprop, then I'll end up with multiple rows. So, the WHERE or the JOIN will have to filter for that, I guess (if we're going to reduce the number of rows to a max of three for each title), and then it'll be necessary to make sure each row is only going into the $retArray once. I wonder what the most efficient way will be? Probably to pull all the page_props for a page and just only use the displaytitle and the bpdprop.

Leucosticte (talkcontribs)

Okay, I got rid of the worst of the database inefficiencies, but it's still doing a totally unnecessary O(n) looped query to get the page title objects when it already did a SELECT on the page table for that data. That was just a lazy hack from my more amateurish and short-sighted programming days. Maybe I'll get around to fixing that later.

Leucosticte (talkcontribs)

Okay, got that all fixed too now. On to BedellPenDragon! Another day.

Reply to "Database inefficiencies"