[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] ✘GPSD_API
From: |
Eric S. Raymond |
Subject: |
Re: [gpsd-dev] ✘GPSD_API |
Date: |
Thu, 14 Apr 2016 04:04:59 -0400 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Gary E. Miller <address@hidden>:
> > > For example, was the recent addition of oscillator_t osc to
> > > gps_data_t a compatible change that should have incremented the
> > > minor rev?
> >
> > I'm pretty sure that breaks the abi as you are chaging the size of
> > structs.
>
> I don't think it does change the size of gpsdata_t since oscillator_t
> was slipped into a union already bigger than it is. I think it should
> been a minor version bump since it should not affect existing programs.
That is correct.
> > you also might want to read
> > http://www.catb.org/esr/structure-packing/
>
> Even embedded systems now have gobs of memory. As soon as we use
> python, or any other garbage collection, the gross handling of RAM makes
> saving a byte here or there in C ludicrous. Page frames allocated by
> the kernel are now 4k or even 4M, so months of work packings bytes would
> be needed to save enough RAM to eventually save one page frame.
>
> I just took a look at my desktop host, gpsd is about the smallest thing
> running.
>
> I'm not saying to be wasteful, but there are way more important things to
> spend time on now than packing structures.
Yes, there are.
I wrote that after wrestling with one of the very few cases where the technique
is still useful - data sets so large that if you don't pack them carefully you
might hit a physical memory limit. The context was cvs-fast-export on *huge*
CVS repositories.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
signature.asc
Description: Digital signature
Re: [gpsd-dev] ✘GPSD_API, Eric S. Raymond, 2016/04/14