Technical strategy and performance

Hal Murray hmurray at megapathdsl.net
Wed Jun 29 21:49:52 UTC 2016


Thanks.

I didn't see any surprises.  I'm happy with the general idea, it's the 
details that get interesting.

Removing cruft is good.  Removing features is not.  There is a trade off 
between the cruftiness of the code and the importance of any features it 
includes.

This example gets tangled up in several issues.

I didn't see much discussion.

I seem to be the only one who occasionally pushes back when you hint at 
removing stuff.  I can't tell if I'm making the right amount of noise or not 
enough or too much.  Most of the cruft you remove looks like progress to me, 
but I can't tell if/when you are going too far.  It's a judgment call.  
Sometimes I don't care much.  Sometimes I do.

One of the complications for this case is that we don't have a good way to 
test things.  This feels like the sort of problem that might come back as a 
hard to debug example way off in a far away datacenter where it would be even 
harder to debug.  I don't like that sort of problem so I'm probably willing 
to put up with a bit of cruft in the code in order to reduce the risk.

You haven't convinced me that modern hardware will make this problem go away. 
 Yes, it will reduce it, but that also makes it harder to test.  Your comment 
about no swap space was timely.  I lost a cron job a few days ago because it 
ran out of memory.  I don't know enough about modern data center operations.  
On VM systems, they charge for memory.  ...

Did you consider simplifying things rather than removing everything?  (Sorry 
for not suggesting this sooner.)  Most of the cruft was in figuring out how 
much to lock.  Would locking everything be simple enough?

-----------

I thought there was a command line switch to use the real-time scheduler but 
I can't find it.  If it's there, it might be cruft to clean up.  If it's not 
there, it might be a good feature.  There would be complications with lots of 
traffic locking up the CPU.

-----------

There is another interesting consideration when using old hardware.  They 
take a lot of power.  At some point, it's cheaper to buy new gear that 
doesn't use as much power and has more memory while you are at it.  I 
computed the pay back time once, and it seemed like a good excuse to get some 
new toys.  The next time I did the calculations, I got a an answer I didn't 
like as much.

-- 
These are my opinions.  I hate spam.





More information about the devel mailing list