Re: [WWdevel] SetMaker is slow!

[John J. <jj...@as...>]

Hi,

Problem caching would probably speed things up considerably.  
Personally, I set the number of problems displayed to 5 to account for 
this (and use display=none as Arnie mentions for some special uses like 
cloning a problem set).  I guess the question is how much disk space 
this will use, especially if you do some sort of pre-caching.

Something else to be aware of is a second cause of slowness in SetMaker 
which this would not address.  When you ask for 1000 problems and only 
display 5 of them, it some how has to keep track of what those problems 
are, with the sequential order in tact, so that it can handle next/prev 
page links.  Currently it stuffs them all in a hidden cgi field of the 
page.  If someone accidentally asks for all problems from 
database_problems, that's 10,000 lines - you might as well kill the 
browser and start over.

It seems that there are 3 options for that: 1) leave it as it is; 2) 
store the information on the server instead of in the page; or 3) 
recompute the list on each refresh to know which problems to display.

The third option probably wouldn't be too bad, but it would require that 
when a list of problems is made, including by a database search or by 
disk searching, that they get sorted into some canonical order.

Option 2 would probably be the fastest for the user, but storing that 
kind of session information is kind of atypical of webwork.

John


Arnold Pizer wrote:

>At 12:16 AM 7/28/2006, Sam Hathaway wrote:
>
>I think something like this would be a very good idea. I almost 
>always use "none" for the display mode when"viewing" a large set. In 
>fact after the first time I tried the library browser, I told John we 
>needed a "none" mode because things were so slow. He added it almost 
>immediately.  The "none" mode would still be useful as it compresses 
>output but most people want to see the problems (not just file names) 
>so speeding things up would be a great help.
>
>Arnie
>
>
>  
>
>>Hey,
>>
>>Does it bother anyone else how slow SetMaker is? It's not that
>>module's fault, it just takes a long time to render problems, and
>>rendering 20 of them gets pretty insane.
>>
>>I was thinking that a solution to this would be to cache the entire
>>output of the problem processor. For non-interactive situations like
>>SetMaker, the only thing we'd need to cache on is the problem seed --
>>other data (like num_correct, num_incorrect, etc.) are always the same.
>>
>>The cache could simply be a file containing the problem TEXT, named
>>based on the source file name and the problem seed, or we could get a
>>little more complex and also store the names of any temporary files
>>that the problem depends on. That way, deleting, say, a generated
>>graph would invalidate the cache and cause the problem to be re-
>>rendered.
>>
>>This would speed up problem browsing TREMENDOUSLY, since PG wouldn't
>>even run once ANYONE had browsed a problem set. This might even be a
>>good candidate for pre-caching -- run through the problem library
>>once with seed 1234 to save a lot of instructor time down the road.
>>
>>Any thoughts?
>>-sam
>>    
>>