Caching jobs

[Michael Biebl]

2007/10/23, Shawn Rutledge <shawn.t.rutledge at gmail.com>:
> On 10/23/07, Jan Claeys <lists at janc.be> wrote:
> > Op maandag 22-10-2007 om 21:48 uur [tijdzone +0100], schreef Scott James
> > Remnant:
> > > The parser is a string one; so it could be faster by being binary ...
> > > but it wouldn't actually buy you anything; you'd have to re-parse the
> > > text files on boot to make sure they hadn't been changed while the
> > > computer was off.
> >
> > Storing the last file modification time inside the "binary blob" might
> > be good enough?
> >
> > (Although I'm not sure this will gain a lot of speed, compared to
> > disadvantages of the relative opaqueness of a binary format?)
>
> Yeah I thought of that too... if checking the time of the script to
> compare it to the blob's update time involves a bunch of seeks, there
> is probably not much to be gained.  (Depends on the fs implementation
> somewhat.)
>
> But if the format was one binary blob in the first place, and you had
> a special editor for modifying it, there is no room for sync problems.

Come on, this discussion is pointless. I doubt, it would gain half a
second, if at all. All we would get would be increased complexity. And
if the format would be binary only, this idea is imho insane. Text
files are much more robust, and for an init system that is essential.

tbh, this all sounds like a solution looking for a problem.

Don't fix, what ain't broken.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?