Closed kaamui closed 3 days ago
Here is the original document. 6.02 gravitation.zip
The first page is way heavier (2.2Mo where page 4 is 824Ko) but loads faster. Seems that groups are consuming.
Also, the vast majority of the time is spent here : https://github.com/letsfindaway/OpenBoard/blob/fff1a15ef00c1428c78db498d9ca63172b5579d9/src/adaptors/UBSvgSubsetAdaptor.cpp#L991-L994
Yes, this is also my experience, and finally in
which is quadratically slow, because it iterates over all existing items. It is called from
This means that the statement in the comment is not true. The z Level is not DEFAULT_Z_VALUE.
The commit adds these lines: https://github.com/letsfindaway/OpenBoard/blob/fff1a15ef00c1428c78db498d9ca63172b5579d9/src/adaptors/UBSvgSubsetAdaptor.cpp#L2380-L2383
I thought I would have to assign the z value of a group, if the item is in a group. Should I better leave it at Default, so that the if
statement does not call zLevelAvailable
?
For me this speeds up loading by about the factor 12 / 5, but I don't know what the correct handling would be.
But perhaps removing these lines again instead of reverting the whole commit would be sufficient.
I'm not sure either. As we didn't have known issues of z-level for grouped items, I think I'll revert.
I prefer reverting the whole thing and revert it back after we fine-tuned it, because I don't want to let potentiel other issues not detected yet. Do you see potential issues reverting it ?
I also noticed that the number of detected strokes differ, with or without this commit, but I didn't investigate.
I'm not sure either. As we didn't have known issues of z-level for grouped items, I think I'll revert.
I prefer reverting the whole thing and revert it back after we fine-tuned it, because I don't want to let potentiel other issues not detected yet. Do you see potential issues reverting it ?
Yes, the duplication of the lines, e.g. the cross of the compass tool.
I also noticed that the number of detected strokes differ, with or without this commit, but I didn't investigate.
I'm not sure either. As we didn't have known issues of z-level for grouped items, I think I'll revert. I prefer reverting the whole thing and revert it back after we fine-tuned it, because I don't want to let potentiel other issues not detected yet. Do you see potential issues reverting it ?
Yes, the duplication of the lines, e.g. the cross of the compass tool.
I also noticed that the number of detected strokes differ, with or without this commit, but I didn't investigate.
OK. Let's try to come to correct performances without reverting all the good changes that have been done.
Do you see a reason why it would still take 5s instead of the second took by 1.6.4 ? I thought it could be the "real-time" thumbnails but it doesn't seem to.
You seem to have better tools/skills than me to profile execution times of each function ... what do you use ?
I'm using the profiler built in to QtCreator, which again is using some of the standard Linux profiling tools.
No, is do not have an idea why it takes 5 sec, but still i See that much time is spent in that zLevelAvailable function. I would probably recommend to tune this, e.g. by using a QSet of used z values, where lookup is fast.
Do you have some insight in the zLevel handling?
For now I have to stop investigating as I have to pick up my wife at the station.
Do you have some insight in the zLevel handling?
Not much, just that now that you say it, the way available zLevel values are searched is just awful ... what do you want to know precisely ?
Thank you for your help
Here are some documents where Z layers are very important : Elec_Exo10-11.zip 1_Elec_FiAct_SC_20-21.zip
Something like that should perform better. https://github.com/OpenBoard-org/OpenBoard/pull/892/commits/8870cfaec63d3a0bdfa71370bfea895bddb3f3db
I don't even understand why we would need more than that. The ZLayerController
does more, but I don't see why available zLevel values could not be handled like this.
Something like that should perform better. OpenBoard-org@8870cfa
Except that you should return !contains
instead of contains
.
Yep, I'll fix it tomorrow, I just wanted to gîve a start to this refactoring and thought that we would both be able to work on the draft PR. Can you or is the original author the only one able to change it ?
Yep, I'll fix it tomorrow, I just wanted to give a start to this refactoring and thought that we would both be able to work on the draft PR.
I tested it and performance-wise is is a huge step and could do the factor of 5.
Can you or is the original author the only one able to change it ?
I think I could push to this branch, but I like to avoid it and only push to my fork. I could then even make PRs for updates of your PR :)
BTW: I'm not available from Thursday (tomorrow) until Monday next week.
Hi Martin,
a teacher juste shared me a document where he was experiencing some loss of data when exiting Openboard (I'll write an issue about that as well, it's an issue with the
PersistenceWorker
). During my testing, I was surprised by the loading time of one of the pages of his document. I started some comparisons about it, and found that there is a huge performance issue with large pages like this one. Unless you have an idea of what could explain it, I'll have to revert this commit for 1.7.1, until we find the answer. Note that this commit is not the only one causing such bad performances, but I didn't identify the others yet.Describe the bug
Huge performance issues are coming with 87df649 fixes.
To Reproduce
Expected behavior
A clear and concise description of what you expected to happen.
The document loads quickly.
Actual behavior
A clear and concise description of what actually happened
I didn't identify where the other 4s of loading time are coming from at this point.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional resources
PDF, images, sounds... anything useful to reproduce the bug 13.02.24 1346.zip
Context
systematic
1.7.0
1.7.1rc-240202
1.6.4
Linux
Windows
macOS
OpenBoard download page
own build
master
Additional context
Ubuntu 20.04.6 LTS
1