On 17.09.24 16:15, Will Godfrey wrote:Indeed, do we need to make it optional at all? The reporting is already user switchable,...On Tue, 17 Sep 2024 19:04:39 +0200 ichthyo <p...@ichthyostega.de> wrote:Accessing the system clock always costs some performance; it is an overhead comparable to an ordered read from an atomic variable, so it's not negligible.On 17.09.24 19:55, Will Godfrey wrote: OK, good point. I think that leaves two practical options. The obvious one is to hide the 'Log Load times' line in Settings->Switches when it hasn't been compiled for - not quite sure how we do that!
On which tab is this setting on? is it one of the toggles?
Anyway, we do disable check boxes for secondary instances, and we do it
right in the code in make_window(). There is an extra field code1{ ... }
which is typically used for that purpose. At that place we could also
hide a widget. Since we can not use conditional compilation directly
in the FLTK generated code, we'd have to place a static flag somewhere,
probably best into the Config object. This flag would then be set by
conditionally compiled code.
Another possibility that might be practical is to use the switch setting to enable/disable the timing code. That way, the only overhead would be a couple of bool tests.
And testing a bool costs less than one nanosecond, but only under the assumption that this piece of data is in the cache and it's hard to guess if this is the case. But, placing that into perspective, our note-on/off code is anything from highly optimised -- I'd guess any note-on processing causes some core memory IO, because, what gets really cache-hot is the audio processing code. Thus my gut feeling would be that testing yet another bool would not even matter on this rather critical path. On the bright side, this would mean we could get rid of some conditional compilation flags, which are a constant source of hidden bugs, since there is a tendency to forget about them (at least for me!)
I actually use this looking for sources of Xruns created by a lot of note-on events at the same time, or an 'expensive' note on at the same time as (say) an instrument change on a different part.
Sure, but would a musician, which is not also an engineer approach that topic the same way? See, I for my part check in my presets into Git and often look into the XML. But I've noticed time and again that other musicians without engineering background tend to approach the use of technology in a much more intuitive way Sometimes I am thinking, maybe we should move into the direction of a "developers mode". That would be a compile switch, but at once activate several diagnostics, like toggle on assertions, produce more diagnostic messages and then also measure runtimes at some crucial points. Obviously without seriously degrading performance. Another tiny observation: in the "Main Settings" tab of the settings dialog, the drop-down list at bottom "Mixer Pannel Layout" is empty, even while the actual setting (one row with 16 strips) is retained correctly. Is this the case also on your system? maybe my default configuration is not up-to-date. I could find the callback where changes to this selection are forwarded to the core, but I could not find the code which processes and sets the current state. Maybe you can recall the place where this happens? -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
