search

JuliaRheology / RHEOS.jl

RHEOS - Open Source Rheology data analysis software
MIT License
40 stars 9 forks source link

Remove _insight debug flag base.jl or document/improve it #138

Open akabla opened 3 years ago

akabla commented 3 years ago

There is a default keyword parameter in all objective function call. I suspect this causes a significant overhead. We should remove it and benchmark the code performance. A global const debug flag might be used if we really need one there.

moustachio-belvedere commented 3 years ago

I found it very useful on numerous occasions, especially when fits are not going well I found it it to be invaluable. I think Ale @ab2425 did too from memory, but we would have to check with her.

If on benchmarking a const global is similar performance then that has some benefits in that it makes the code cleaner and could easily be used in other functions as well. However, a major drawback of being a const global is that it is const, and thus can't be changed by the user. So it becomes enforced as a feature only usable by those comfortable enough with Julia to investigate RHEOS internals and would force recompilation of the module each time it was changed. Both implications are undesirable.

Would be curious to know what overhead it adds. My bet would be that its presence as a parameter is negligible. The branch in the function body may add a little more overhead but this would still be required if we used a const global. Also, I would expect the branch to be negligible compared to mittleff, convolution and any other operation we perform over large arrays. Branches like that can often occur in one CPU instruction Vs many for array operations.

akabla commented 3 years ago

I agree that when a complex function is called, this is probably insignificant. Maybe we should think more broadly about how to assist the user tracking how the optimisation evolves. It is indeed useful. Maybe we could make it feature!

moustachio-belvedere commented 2 years ago

Thinking about this again recently:

Maybe we could make it feature

It's a feature already; it's not extensively documented but it is in the API section, which is enough I think. Maybe we could add it to an example.

Maybe we should think more broadly about how to assist the user tracking how the optimisation evolves

I was reading about this the other day - https://docs.julialang.org/en/v1/stdlib/Logging/ the @info macro could be one way to extend logging as a more general feature. From a 1 minute exploration, I don't like how much extra noise comes with it (2 lines output for each invocation of the macro) because it means more mess when printing out lots parameter iterations. But something to explore further, I'm sure there's room for customization. We should also benchmark.