Custom Profile Fields and Performance

[squishi]

For an extension that I am creating, I have added many custom profile fields.
The vb_userfield now has 71 fields. About half of those fields belong to my extension.

These extra fields are only necessary in my extension. I guess they are loaded in other parts of the forum as well, where they are actually not needed.
I could remove the extra fields and add them to a special database. The downside is that I would have to do all the validation in my script.

From a performance stand point, should I remove the custom profile fields?
Should one keep the field count as low as possible?

[Lynne]

Are you sure they are getting loaded in other parts of the forum all the time? I'd go into debug mode on your test site and look at the queries and see when the other fields are actually getting loaded. Perhaps it would be easier to modify those queries in the code rather than create your own table to hold them and have to do all the validating.

[squishi]

It's userfields... I would think they get loaded for example in the postbit for each user.

About the debug mode... I was notified that members of my site can see the debug output. Is that the default behavior of vbulletin's debug mode? Why was the debug output not wrapped with a admin permission check?
Is there a possibility for me to wrap the debug output with a conditional?

[Lynne]

Yes, that is the default for debug mode. It's a tool to use on your test site where you actually write your code. I leave it on all the time on my test sites.

You can wrap it in a condition if you need it on your main site:

PHP Code:

if ($_SERVER["REMOTE_ADDR"] == "xx.xx.xx.xx") {
    // enable debug mode for only the IP xx.xx.xx.xx
    $config['Misc']['debug'] = true;
} 


[squishi]

That's a good idea and has helped me find some uncached templates.


In debug mode, I see that all userfields are queried twice on a showthread page.

Once for the user who is browsing the page:

SELECT 
	userfield.*, usertextfield.*, user.*, UNIX_TIMESTAMP(passworddate) AS passworddate, user.languageid AS saved_languageid,
...
FROM vb_user AS user
LEFT JOIN vb_userfield AS userfield ON (user.userid = userfield.userid)
...
WHERE user.userid = 1

And as I suspected, they get queried for each individual post as well:

SELECT
	post.*, post.username AS postusername, post.ipaddress AS ip, IF(post.visible = 2, 1, 0) AS isdeleted,
	user.*, userfield.*, usertextfield.*,
...
FROM vb_post AS post
LEFT JOIN vb_user AS user ON(user.userid = post.userid)
...
WHERE post.postid IN (0,167,264360)
...

I am not planning on upgrading my forum anymore. So edit of the source code are not a problem for me.

So you would rather edit those queries instead of creating a new database table for the fields?

[Lynne]

Me? I don't know which I would do since I have no idea what your profilefields do or where you need them.