Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Priorization of LCDproc features #2779

Open
markus2330 opened this issue Jun 13, 2019 · 3 comments

Comments

Projects
None yet
3 participants
@markus2330
Copy link
Contributor

commented Jun 13, 2019

  1. having the possibility to start LCDproc without any installation/mounting (built-in spec)
  2. installed size
  3. memory footprint
  4. binary size
@haraldg

This comment has been minimized.

Copy link

commented Jun 13, 2019

There obviously isn't a general answer.

4 is basically just a lazy way to monitor changes to 2 and 3.

For OpenWRT it probably would be 231 most of the time
For my other systems it will be 321 except for my development workstation, where it is 14.

All these numbers assume that saving one byte in 2 costs one byte in 3. Even on OpenWRT I'd still sacrifice one byte on 2 to save say ten bytes on 3.

In the end there rarely is a true conflict among 234 and 1 is just a question of having some kind of convenience hack for development builds. (Eg at the moment we just pass a non-standard configuration file on the command line, if it isn't installed into the system yet.)

@kodebach

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2019

4 is basically just a lazy way to monitor changes to 2 and 3.

IMO installed size would include a separate specification file, if it has to be present, while binary size would not include that. The memory footprint is probably also not proportional (at least not in any obvious way) to the binary size. A load of strings will increase both similarly, a load of keyNew calls will increase memory usage much more than binary size (because of the key unescaping logic).

@haraldg

This comment has been minimized.

Copy link

commented Jun 13, 2019

Yes, of course all these things have to be considered. Still I think comparing binary sizes gave us a lot of useful information. Once the obvious issues are solved, I might move to more advanced benchmarks, that involve actually running the code or building binary packages for various platforms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.