Removing unused features

pjft

To conclude simplifying the code is the only solution apparently.

Not necessarily the only solution, but until there's a clear need or data to justify removing features, I believe it's not the solution we would want to pursue at this stage.

I had thought at one point of adding analytics hooks to ES and reporting on usage patterns, options and such to a centralized server for us to be able to best determine what was used more often or not. That would inform these decisions a lot better.

That being said, it's probably more bloat to the code base :P

But hey, I'm sure by Q4 or something if I'm kind of running out of ideas, I'll implement something like that. I had thought of other interesting "connected" applications, like knowing what games are the most popular every week... but once again, not for now, if ever.

Hex

@pjft I would very much like these kind of feature that can be toggled by user so privacy conscious people dont complain about it. I sure would bloat the code a lot. We could even separate this feature and provide hooks to ES to minimize code.

pjft

@Hex Oh, certainly. Anything that would report any kind of data to a server would need a previous explicit acceptance from the user, and would never be mandatory. And it would always be anonymized and aggregated as well, just for analysis.

But you're right - that's a whole new can of worms I'm not especially sure I want to open. I was just using it as an example that had crossed my mind a few times in the past :)

meleu

Recently I was tweaking RetroArch code and this thread here reminded me that there are dozens of flags in RetroArch code that provide several ways to build it. For example, for a really lite RetroArch, with no XMB, no networking, no retroachievements, and many other features, you can compile it using:

make HAVE_XMB=0 HAVE_MATERIALUI=0 HAVE_NUKLEAR=0 HAVE_ZARCH=0 HAVE_OVERLAY=0 HAVE_LANGEXTRA=0 HAVE_LIBRETRODB=0 HAVE_NETWORKING=0 HAVE_NETLOGGER=0 HAVE_CHEEVOS=0 HAVE_NETWORKGAMEPAD=0 HAVE_MINIUPNPC=0 WANT_IFADDRS=0 HAVE_SOCKET_LEGACY=0

Maybe this can be done on ES code too. One example, people who use RetroPie on devices powered by a battery probably won't use video preview. So adding a way to compile ES with no video preview should be useful for that use case.

Now, the obligatory joke: this is how I feel in my RetroArch code adventure:

Zigurana

@meleu I've felt the same way about ES for a long time. Maybe I understand it better now, but maybe I've just gotten used to it <shudder>.

Hex

@meleu @Zigurana Are we setting up builds to work with flags first? Does using said flags reduce compile time?

Zigurana

@hex
I don't know.
Do you mean using general compiler options to change the optimizations done during compilation? Or do you want to introduce new flags to enable /disable specific files to be included in the first place?

In either case, without a better (data-driven!) understanding of what the current bottlenecks are, this is not likely going to be the solution to our problem.

meleu

@zigurana

In either case, without a better (data-driven!) understanding of what the current bottlenecks are, this is not likely going to be the solution to our problem.

I googled a bit and found this question:
https://stackoverflow.com/questions/10577793/how-should-i-detect-bottleneck-of-compile-time-in-a-large-c-project

The answers indicates that taking a careful look at the #includes is a good place to start.

Hex

@Zigurana I was thinking in terms of flags like "Extensive" "Minimal" to decide on settings options (Optionally there could be a KIDS flag too). Then "Performance" "Powersaver" "Dynamic" for Power. ETC.

These would ideally work like RPI flag works currently. This way we can have a single code base while allowing default options for all users and extensive abilities for dev builds

pjft

Not that I don't believe in compiler options and such - as I believe I also suggested that a while ago for the Pi Zero, for instance - but won't the default for the majority of the users be the full shebang of options, though?

I feel I'm missing the overall goal and use case here, though. This started out as removing unused features from ES, and it quickly turned into speeding up compilation. What's the target for this, though - is it mostly for testing builds? Development? I'd imagine we can only fully test something when we're running the full binary the majority of users will be using, as unexpected interactions across all the components are usually the main source of unforeseen bugs. During the development, we tend to (hopefully) just recompile changed files, so for the most part it isn't a big time sink - or, at least, not one that would be significantly reduced via these flags I feel.

"Settings" should not be set via compiler flags, but be accessible to end-users.

I'd be supportive if someone wants to invest in a single flag for a "lite" version of ES for Pi Zeros and such (removing audio, video, animations, and whatever other bells and whistles there'd be, and having power saving on), in order to provide different binaries for those Pis, if useful. Anything more than that, for the time being, might be a bit of over-engineering, in my opinion, though we'd be opening the door to platform fragmentation, and every new feature we'd need to be mindful of how it'd interact with the different builds. I'm not sure the added complexity is desirable at this stage?

My Thursday 2 cents.

BuZz

The only flags I might consider would be a define to disable building in video support or not if it was done cleanly - but this wouldn't be used for RetroPie, but it could be useful for people building from source who wanted to exclude them (someone requested this on the issue tracker I believe).

I have no issue with current compile time, nor do I think flags/defines for enabling/disabling features would be much use. I wouldn't accept any PR for such things without being convinced why we would need it.