My Community
The Stackz Concept => Requests and Reports => Stackz - New Feature Requests => : houkouhaikai July 06, 2006, 07:25:17 PM
-
Firstoff, I know that this is a huge and probably useless one but I thought I could as well give an idea what can still be improved.
Okay, I am aware of the fact that it might not be the smartest idea to have like 7000 cards in one stack...but I still like it like that. Random reviewing without seperation is just the best for me.
But stacks is getting slower and slower in testing mode...to mark a card as known or unknown takes like 5 seconds on my machine. Maybe I'm an idiot but I think that this needn't be. After all it does not need to rewrite every sub-stack just because I answered one card. Sure this might be useful for people who want the graphic of the stacks to be updated after every card...but an option to update the stacks after more entries and doing it in the background might make it better. I mean it should be possible to instead of rewriting the two stacks that are influenced by answer, which I assume is what is wasting most performance atm, to just make a small memory area where it stores what is to go to which stack eventually and then when it has spare performance do it or do it more infrequently on larger stacks, or maybe some other way.
-
I know that this doesnt really address your issue, but having 7000 words in one lesson has many downsides and no real benefit that i can see. If you divide the 7000 words into seperate lessons (example:100 words per lesson) within the same file then you can focus on specific areas if you choose, or just select all and test if you feel like doing random reviewing for all 7000 words... Even better just choose a random lesson or 2 each time (still random but it should run substantially faster).
Just a suggestion.
Peter.
PS: im not affiliated with stackz in any way by the way, this is just the opinion of another user! :D
-
The speed does not change if the cards are split into lessons. All cards are updated because this is necessary in some situations, e.g. if you use the FailureCount ColorMode and increase the maximum failure count with your action, then the color of all cards will have to change.
This complete update has never been considered as an issue so far. My biggest file contains 6400 cards and a test action on my 2.5 GHz 512 MB ram PC takes way less than a second - around the time needed to pronounce the word "hop", and I assumed that noone would ever use a file that big in reality... :)
Speed improvements are certainly possible, the simplest way is the suggested update prevention. More advanced things like partial update only where needed are of course possible as well. The additional complexity and potential error source did simply not seem to be necessary so far. We will investigate this and provide a solution in an upcoming version.
Is it running faster if you hide the main window during testing? You can do so by holding down the ctrl key when opening the test dialog. I'm not sure how the system reacts on your PC since I can't duplicate the slow behavior in the first place, but it might be faster by chance...