On 3/27/22 4:17 PM, Ted Felix wrote:
Turns out no one was ever writing to those settings, so they weren't
actually being used at all. I removed the use of QSettings in
GUIPalette and pushed as [bcc713e7].
Should be something of a performance bump. Please test latest git.
I tried the change (in the context of my branch's HEAD) and didn't see
much difference, either positive or negative. Maybe what I test isn't
hitting the palette code. Regardless, in my opinion the new version is
indisputably more correct.
On 3/27/22 3:07 PM, mark_at_yahoo wrote:
> Thanks, David. I'm primarily seeing pauses when switching ME display
> modes, particularly with the new ones I've added in my FR
> branches. I'll see if I can come up with a recreatable example
> using only note names in master.
I did, and yes, it was the same QSettings problem. The [659efa2699]
commit to implement FR #489 instantiates and queries a QSettings in
MatrixElement::reconfigure(timeT,timeT,int,int) which is called for each
note in each displayed segment. With 10K+ notes this was taking 20-30
seconds in some cases when turning off note names.
Once again ironically, when I implemented similar per-note configuration
for FR #501 and #503 I instinctively cached the persistent QSettings
values for quick access. I didn't, and don't now, know the full
implications, but I suspected that at best accessing the database, and
at worst going to disk (or the "registry" under Windows), would be an
unacceptable performance hit.
But that brings up another question: Even though in most cases the
QSettings performance isn't a problem, what would be the implications of
(taken to the extreme) creating a global instance when Rosegarden
starts, using it everywhere in the code, and destructing it at program
exit? You wrote that the constructor does the expensive read of the
config file(s)/registry. I'm assuming that QSettings::value() does not
and is therefore at least reasonable fast. But when are the
files/registry written? In the QSettings destructor, or at each
QSettings::setValue() call? In other words, if there was a global
QSettings instance, or more reasonably separate/individual long-lived
ones (per editor or something) and Rosegarden crashes or otherwise exits
incorrectly, are pending user-changed settings lost?
One more performance-y thing: I implemented both hide()/show() instead
of removeItem()/addItem() for the thousands of note names, and also
changing to QGraphicsView::NoViewportUpdate before doing them. Neither
made much speed difference, especially compared to the
orders-of-magnitude boost from removing the QSettings constructor calls.
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
