All about the OSDev Wiki. Discussions about the organization and general structure of articles and how to use the wiki. Request changes here if you don't know how to use the wiki.
Projects: Ye flipping gods, up to half a minute. Editing is worse. Diff takes upwards of a minute. Sometimes loads in three seconds if I'm feeling lucky.
I don't know about you, but I think that's pretty damn slow. It makes sense that the larger the page, the more you have to download and the more PHP has to process. But come on. I can load a page of forum posts equal in size to the Projects page in less than a quarter of the time. Either mediawiki's too slow or we're doing something wrong.
Anyone have this problem? Any ideas? Thoughts? Comments? Flames? Wait, scratch that last one.
Solar wrote:It keeps stunning me how friendly we - as a community - are towards people who start programming "their first OS" who don't even have a solid understanding of pointers, their compiler, or how a OS is structured.
Diff is always going to be slower than a static page if it's dynamically generated, though I'm not sure how mediawiki handles it. It might store the diff as a static page but IDK.
Troy Martin wrote: * Projects: Ye flipping gods, up to half a minute. Editing is worse. Diff takes upwards of a minute. Sometimes loads in three seconds if I'm feeling lucky.
I haven't experienced more than 5-10 seconds loading time.
Either way, we should consider putting the content of the projects page in multiple pages. It should be easy (afaik) to have each entry become a separate page in a "Projects" wiki category. Then multiple entries could be listed side by side, things would be automatically sorted, and the total text on the central projects page would shrink twenty-fold. Or each letter could have its own page. Would either of those things actually be faster?
At the very least, the list could handle some garbage collection.
I suggest breaking Projects into A-F, G-Q, and R-Z (or something like that, at the very least) in order to speed up loading times dramatically. A page for each project is a little over the top.
Solar wrote:It keeps stunning me how friendly we - as a community - are towards people who start programming "their first OS" who don't even have a solid understanding of pointers, their compiler, or how a OS is structured.
Someone could always make a quick mirror test where you keep the original page intact, but test out the proposed solution to see if it actually works. I do not think anyone would mind as long as it did not change the original until the results could be verified. I imagine someone who works on the wiki a lot could post here and help bring up any potential issues in doing so.
I know that Combuster could point out any problems that could arise, and if none then I know he would be happy to let someone test it out or something.
I honestly have no idea and do not want to invest any time in it myself, unless it actually is a problem and no one else will do it then I would test it out and try it.
Could it be something to do with the macros that we use?
Troy Martin wrote:[*]Projects: Ye flipping gods, up to half a minute. Editing is worse. Diff takes upwards of a minute. Sometimes loads in three seconds if I'm feeling lucky.[/list]
Depending on how many other users are accessing the site at the same time, it'll get slower and slower, but it's not necessarily just the page (download speed etc...). It may be more effective to have ranges of first letters as Troy Martin suggested, but I believe that comes at a cost. If the project list is no longer in a single page it may be that projects get overlooked or missed altogether.
Perhaps a better course of action would be to cull the projects list of all the halted/cancelled/dead projects?
What about moving the project page off the wiki, and requiring the project owner to register initially; followed by a you-might-get-removed email with a reactivation link every, say, 6 months (with the removal if they don't in like 30 days)?
I don't know about moving it off the wiki, but an automatic periodic PM/email to the owner of each project to check if it can be removed might work. The issue is that it could remove old, inactive, but still decent projects. Still, in this state, it's hard for anyone to find projects.
We could have an inactive projects page, rather than straight out deleting them.
My suggestion though, is have minimum standard for projects to be included. That is, exclude all the 'Hello, World!' projects (or place them on a 'Small Projects' page) and the list will be cut down significantly. It'll have to be a case by case basis rather than a strict definition, for example, an exokernel and a monolithic OS are going to be judged by very different standards.
My second suggestion (it won't actually improve loading times) is make the summary be more specific. For example, "will have a GUI and networking" is a misnomer when in actual fact it's has a hard-coded command line and can read text files off a floppy.
