AMC performance on postcorrection

Added by Roberto González almost 9 years ago

Hi, everybody.

I'm using AMC 1.2.1 for postcorrection with nominative separate answer sheets on OpenSUSE 12.3 on both, a VirtualBox installation and a laptop with 2GB RAM and a dual-core AMD processor. However, I have noticed that the following processes take a great amount of time in order to get completed:

1) Creating the nominative separate answer sheets for even a small group of students (for a group of 5 members only, it can take almost 5 minutes).
2) Making the marks scale to compute each student's final score: with a group of 37 students this process can take over 45 minutes to complete. I really was very surprised of finding that even the automated data capture was faster than the process of making the marks scale.

I'm not sure to report this as a bug... maybe some settings change can fix it? Is this issue related with some kind of LaTeX processing limitation (I'm not sure if LaTeX plays an active role in the processes above). Is someone else experiencing the same issue (it seems that something similar has been reported in the French forum: Performance d'AMC sur 640 copies ...sorry, my French is really poor).

Thanks in advance.

Roberto.


Replies (18)

RE: AMC performance on postcorrection - Added by Alexis Bienvenüe almost 9 years ago

Can you send your source file?

RE: AMC performance on postcorrection - Added by Alexis Bienvenüe almost 9 years ago

Perhaps this comes from using ovals as boxes (with \AMCboxDimensions{shape=oval})?
This would be good to have a faster implementation of oval/circle boxes. Currently this uses Tikz each time one box has to be drawn.

RE: AMC performance on postcorrection - Added by Roberto González almost 9 years ago

Alexis Bienvenüe wrote:

Can you send your source file?

Here is my source file.

source.tex (6.1 kB)

RE: AMC performance on postcorrection - Added by Roberto González almost 9 years ago

  1. I'm processing a set of nominative separate answer sheets for almost 160 students. AMC started the process of making marks scale at 13:30. Currently it's 18:54 and AMC is still making the marks scale. If this issue is related to the use of the Tikz package, is this waiting time as long as it's supposed to be (even taking into account that this will take more than be expected)?
  2. Next week, we are going to give rolling up tests to a new set of students applying to our school. The format with ovals was chosen instead of the one with squares because, for students, it's more easy to fill in ovals than squares. So, is there any way to get ovals in the answer sheets without using Tikz? Any way to improve the correction speed?

Thank you very much for each answer you have given to me until now :)

RE: AMC performance on postcorrection - Added by Alexis Bienvenüe almost 9 years ago

  1. You can try to comment out the \AMCboxDimensions{shape=oval} before updating the marks scale and see if it is faster.
  2. I hope so, but I can't say when I will be able to code this.

RE: AMC performance on postcorrection - Added by Anirvan Sarkar almost 9 years ago

Alexis Bienvenüe wrote:

This would be good to have a faster implementation of oval/circle boxes. Currently this uses Tikz each time one box has to be drawn.

Why hasn't your ovals-savebox.sty from #27 been implemented in AMC? I tested it and it works way faster than the current developement version.

RE: AMC performance on postcorrection - Added by Alexis Bienvenüe almost 9 years ago

It has to be adapted a little to cover all the usages, but you're right: I think Roberto can use it.

RE: AMC performance on postcorrection - Added by Anirvan Sarkar almost 9 years ago

Also, using storebox instead of savebox produces a pdf file of smaller size. Though I don't think it will make much difference with tests created with AMC.

RE: AMC performance on postcorrection - Added by Alexis Bienvenüe almost 9 years ago

Storebox sound very interesting, thanks!

RE: AMC performance on postcorrection - Added by Roberto González almost 9 years ago

Why hasn't your ovals-savebox.sty from #27 been implemented in AMC???
It has to be adapted a little to cover all the usages, but you're right: I think Roberto can use it. ??

How is it supposed to be implemented in AMC for the usage I'm doing of it?

You can try to comment out the \AMCboxDimensions{shape=oval} before updating the marks scale and see if it is faster. ??

Won't it affect any other stage of the correction process? I mean, I'm supposed to modify a feature of the project's source file. Should I bear in mind any specific task in which the original code must remain unchanged, so I will need to uncomment the \AMCboxDimensions{shape=oval} ?

RE: AMC performance on postcorrection - Added by Alexis Bienvenüe almost 9 years ago

How is it supposed to be implemented in AMC for the usage I'm doing of it?

For your current usage, you can use it as it is.

Should I bear in mind any specific task in which the original code must remain unchanged, so I will need to uncomment the \AMCboxDimensions{shape=oval} ?

No. This has to be uncommented only when updating the documents, but once you have printed the questions, you should never update the documents.

RE: AMC performance on postcorrection - Added by Alexis Bienvenüe almost 9 years ago

I added the savebox related code in revision r1474 (and I'm not sure this is compatible with ovals-savebox.sty, so maybe you will have to drop it in your sources).

RE: AMC performance on postcorrection - Added by Roberto González almost 9 years ago

Alexis Bienvenüe wrote:

I added the savebox related code in revision r1474 (and I'm not sure this is compatible with ovals-savebox.sty, so maybe you will have to drop it in your sources).

What do you mean by dropping ovals-savebox.sty from my sources? I dont' see any line of LaTeX code containing this in the .tex source file.

I have to add that, as you suggested before, I commented out the \AMCboxDimensions{shape=oval} , and the process of making the marks scale was faster (although it took about 2 hours, but this was better than the last time, when the same process took more than 6 hours).

RE: AMC performance on postcorrection - Added by Alexis Bienvenüe almost 9 years ago

What do you mean by dropping ovals-savebox.sty from my sources?

This was for Anirvan, who currently uses ovals-savebox.sty.

RE: AMC performance on postcorrection - Added by Alexis Bienvenüe almost 9 years ago

although it took about 2 hours

Very strange. How much memory did you give to your VirtualBox?

RE: AMC performance on postcorrection - Added by Roberto González almost 9 years ago

Well, that's why it was strange for me too. The processing time I was referring to, was obtained with the laptop installation of openSUSE 12.3.

According with KInfocenter, the general system properties are the following:

  1. OS Version: Linux 3.7.10-1.16, openSUSe 12.3 (i586)
  2. Processor 1: AMD E-300 APU with Radeon HD Graphics.
  3. Processor 2: AMD E-300 APU with Radeon HD Graphics.
  4. Max. processor speed: 1300
  5. 2GB RAM

Within a few days, the school I work in will receive a new group of students applying for the next year. I'll report the results here, with the workaround you suggested (commenting out the \AMCboxDimensions{shape=oval} ). Maybe this only was a temporary issue.

Kind regards.

Roberto.

RE: AMC performance on postcorrection - Added by Joris Heyman over 8 years ago

Hi,

I'm updating marks for 144 students... since 1h... I think it is because I shuffled the order of questions and answers, because when I did not it was much quicker... Any advices ?

Thanks,
Joris

RE: AMC performance on postcorrection - Added by Roberto González over 8 years ago

Joris:

I had a similar issue last year. I was using ovals instead of squares because it's easier filling ovals than squares. Unfortunately, this made the grading process very slow. The only way I could make it take less time was commenting out the \AMCboxDimensions{shape=oval} line (suggested by Alexis). Sadly, it only made the process to become a little faster than before.

I don't know if there is a better workaround.

Regards.
Roberto.

(1-18/18)