xiphonics/picoTracker

Optimising code base

Opened this issue · 3 comments

shockdesign commented

This is a bit of a big discussion here but I think relevant given our hardware.

The entire codebase is written to be flexible and portable given its adaptability to many other devices which to a point we can still build picoTracker to other hardware.

  1. Do we still want to contribute our enhancements/changes back into LGPT?
  2. If not, is it worth looking at scaling back most of the object-oriented spaghetti to reduce complexity and streamline development purely for the picoTracker (i.e. removing support for everything else)

@democloid Let's discuss. This really is a future direction discussion but I think worthy as code path complexity and the oop nature of the code is definitely having a performance impact.

I don't want to discuss how this would be implemented in this thread, just whether it's something we need to consider and it's something we can work towards going forward, not having to do it all in one big chunk.

democloid commented
  1. No, not the focus right now and will not optimize for it. If someone wants to do it they can of course.
  2. Yes, to a certain degree, but I want to be cautious not back ourselves into a corner by doing so. So my preference is to only do it if it serves another purpose.

Right now, this is where I'm focusing most of my attention and I'm doing some heavy refactoring in order to have much better memory guarantees and be able to develop with less probability of breaking something random due to memory issues. I'm also simplifying the code and removing #ifdefs where it makes sense.

maks commented

@shockdesign while it's possible to over do things with OO, alot of C++'s OO abstractions are not expensive performance wise while the benefit is you can see how easy and clear it was to add the pico specific code to lgpt with not very many #if def's required. This structure would be of benefit in future for instance adding support for different audio hardware or even a different microcontroller.
But I agree on not worrying about maintaining lgpt compatibility and really there is no upstream LGPT to contribute to as the original repo is basically abandoned and the only active form that I know of is @djdiskmachine one.

djdiskmachine commented

I agree for the most part, although most of the features I've contributed with are features that I made first for my fork. Some needed some rework, others needed more, but I don't see much need to maintain compatibility. 🙂

  • 👍1