http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Yeah, we get it, ayende can't do math. Get over it, it doesn't matter, because instead of discussing some math and moot problems would you please listen to the POINT of it? Not only are you getting ONE developer to set it up, but the next guy to change the system. And the BA who is asking the developer how long it will take to get this and that customer values stored. And then the BI guys trying to figure out what customer did what. And then the next developer trying to refactor some code and he can't figure out what it does. That second developer who inherited the code leaves. The next guy they hire doesn't do anything for the first half year other than trying to figure out what the system is storing. No matter how money much each of those ppl make, they will spend a lot of time deciphering the intend and asking other people about what the system is doing instead of being presented with it. Not only disk space has a value but also the information stored on it. That can not be measured because information means different things to differnet people. Somebody put a money value on INTENT please and do the maths again. Last thought: The currency is a developers sanity not the money a company spends on him. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment92http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment92Wed, 17 Nov 2010 02:05:36 GMTMore harm than good, I will not do. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment91http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment91Tue, 16 Nov 2010 06:44:41 GMTI have seen few programmers aware of this. The old thinking schema where economy (of space, processor time, network capacity etc ...) is a priority are still alive. I've seen many costly hours completely lost to the drain trying to debug or adding new features to existing so called optimized programs. Once, a collegue told me that he was reluctant to call his variables with long explicit name because his code lines were superior to 80 char / column ! He had a 26 inch screen ... http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment90http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment90Sat, 30 Oct 2010 09:41:10 GMTmysql and more data storage systems do not store the name in each row, the data is stored in order, with some sort of system to figure out where what set of data ends and another starts, and some sort of system to till when one row ends and another starts... in mysql names are only stored in the .myfmt file, in mysql MEMORY tables names are still storied in a .myfmt file, and if this new system they switched to doesn't do the same thing as a mysql MEMORY table, then it cant be any faster then mysql, normal, or MEMORY http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment89http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment89Fri, 29 Oct 2010 08:51:03 GMTCrazy crazy crazy. There are still some people who argue that hardware cost > software cost, especially for software optimization? http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment88http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment88Wed, 27 Oct 2010 06:15:03 GMT@José F. Romaniello Yes, I mean fine tuning. Buying hardware because each query is a Select * (select star) or because some queries are really bad is WRONG. What I mean is, suppose that queries are good, is not worth triying to do fine tuning (such as forcing execution plan etc etc) only to save hardware costs. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment87http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment87Tue, 26 Oct 2010 09:10:30 GMT@foobert, You may wish to note that Ayende is the principal commiter of RavenDB, which *is* a schema-less database. Also, the article in question specifically mentioned that the abbreviated names were for *disk space* savings, not memory. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment86http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment86Mon, 25 Oct 2010 21:26:37 GMTI seriously how those figures are wrong. Two weeks vacation?!?! Thank god I don't draw my salary in USD. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment85http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment85Mon, 25 Oct 2010 18:39:36 GMTMemory is expensive in the cloud. It's even expensive when you run your own servers. 99% of the people commenting here (including the author), need to familiarize themselves with a schemaless database (yes, it's not so much like your mysql) and also MongoDB. Say what you want about MongoDB, this isn't really something serverdensity can do about. There's plenty of overhead with each document in MongoDB and they utilize it at a rate most of you guys are never gonna see, ever. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment84http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment84Sun, 24 Oct 2010 22:47:14 GMTOk, MongoDB stores data in BSON format in memory. But such old-school optimization does not feel right. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment83http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment83Sat, 23 Oct 2010 17:58:05 GMTAhhh, I can't resist, such nonsense. This brings back memories, all too fresh unfortunately, of silly things I've found in a legacy SQL database: somebody had stuffed an HTML document in an XML document, compressed it with Deflate64 and than stored that in the database. Seriously, what were they thinking? Well perhaps they've read a blog post somewhere along the same lines with the post you mention. This is right up there with one of my leads requesting all variable names use no vowels a few years back. Really? A well designed/scalable application will run without issues on commodity hardware and disk space is really that cheap. I've seen many more availability issues caused by poor design/code than hardware failure, and let's face it hardware fails. Yeah, that's what it does. Your application better handle it gracefully, and you're definitely not going to be accomplishing that with shortened filed names. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment82http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment82Sat, 23 Oct 2010 16:30:43 GMTI do like the very first row, which appeared after your publication: 'A discussion about the value of shortened field names has generated a lot of traffic to this post over the last 24 hours' :D http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment81http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment81Sat, 23 Oct 2010 15:57:15 GMTI wanted to stab a developer in the head when she suggested heavily abbreviated field names. She came from a mainframe background when they counted bytes, I guess she used core memory or punched cards or something back then. Thank god she retired, and I got my way. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment80http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment80Sat, 23 Oct 2010 05:41:21 GMTI don't understand why MongoDB storing everything in RAM is bad? If it makes it faster, it's a good thing right? If a SQL db would store everything in RAM and it would make it faster, I'm a happy developer. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment79http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment79Sat, 23 Oct 2010 04:23:36 GMT1 TB = 60 USD 1 GB = .058 USD cost savings: 59.95 per annum, you're confusing the new cost with the savings delta. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment78http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment78Sat, 23 Oct 2010 03:35:02 GMT"I see this sort of thinking all the time - I'm a front-end web developer and some people squish their CSS files into one giant line. Yeah they save spaces, tabs, and line breaks - but it takes so long to track that down. I mean sure, if you're Google or Facebok go right ahead and make your stuff small because it adds up - but this practice of 'overoptimizing' code for a site that gets >300 hits a week just renders it a nightmare to work on :-/" - innovati The practice you are referring to is called "minifying" and there is no excuse not to do it with your .js and .css files. You simply have your development files that aren't minified for easy editing and you minify those files each time a change needs to go to your production server. It takes 2 seconds to minify .js and .css files using any number of free tools out there. It's just plain lazy and disrespectful to your clients not to. You should also consolidate your .js and .css files whenever possible. Chrome has a wonder auditor built into its developer tools that makes that last bit of optimization easy. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment77http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment77Sat, 23 Oct 2010 01:35:27 GMTYou can save much more money/space by not letting a developer EVER touch a production machine. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment76http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment76Sat, 23 Oct 2010 01:08:35 GMTWhy not just turn on page or row compression and save the space without the work? Oh. Right. MySQL... http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment75http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment75Sat, 23 Oct 2010 00:58:49 GMTTo all those trying to argue that Oren's argument was bad because MongoDB does store the full column name in memory for each row - all you're doing is explaining why schema-less DBs are generally poorly conceived and poorly implemented. Also, it's irrelevant to the point of his argument, which was really about misguided optimizations. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment74http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment74Fri, 22 Oct 2010 23:58:32 GMTOnce upon a time, shorter variable named did mean faster compilation or faster execution at runtime. Back in the days when a 4MHz Z80 was state of the art, anyway. Nowdays you'll pay more (in time) for a processor memory cache failure than for the processing time for a longer identifier. Even if there was a benefit (which I doubt), human time is the controlling factor, not cpu time. If you need to work half an hour late *just* *once* fixing a bug caused by misunderstanding code with cryptic names then you've undone all the potential savings. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment73http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment73Fri, 22 Oct 2010 23:50:27 GMTJust use column constants in your code and then everyone is happy? I think that talking about price is pretty meaningless. If you have enough records that is is a problem, then you'd rather fit in more in memory by making them smaller. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment72http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment72Fri, 22 Oct 2010 23:46:56 GMTYour computation is incomplete. Data center server hard disks cost more than 120 $. Shorter variable names mean shorter build times, because they compile faster. And you forgot the saved wattage for both developer work stations and servers. Keep in mind that green computing is all the rage now. Shorter variable names = saving earth! http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment71http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment71Fri, 22 Oct 2010 23:38:32 GMTLance, stfu please :) http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment70http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment70Fri, 22 Oct 2010 22:54:06 GMTKen is right. The rest of you are a bunch of Ayende fan boys. My god you are like a bunch of blind deaf sheep. If Ayende proclaimed the earth was flat you would happily defend that statement. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment69http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment69Fri, 22 Oct 2010 22:38:38 GMT"This means things are much more flexible for future structure changes but it also means that every row records the field names." There is the real problem. What kind of pathetic database would make such a chronically stupid design decision? http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment68http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment68Fri, 22 Oct 2010 21:19:53 GMTSoftware Engineer :: Document databases.... read the comments http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment67http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment67Fri, 22 Oct 2010 21:15:06 GMTSome facts people: 1. MongoDB store data in BSON format. which means that for every record, the field names are stored with the record. Just as any other schema-less document db (or KVP store) do 2. MongoDB is storing data on a Memory-Mapped-File. Meaning that for optimal usage you'd need to have most (if not all) of the data in RAM. This is what makes it so damn fast. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment66http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment66Fri, 22 Oct 2010 21:09:18 GMTIs everyone missing the fact that column names don't take up *ANY* extra disk space per row except me? They didn't save a damn thing. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment65http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment65Fri, 22 Oct 2010 20:00:40 GMT"Memory is still ridiculously expensive" - especially if we are not using it wisely. I mean what kind of application needs for example 24GB of data in memory at once ? What time is typically needed for app to access let's say 80% of that bytes in RAM ? And another point - that app must make very little income to call 24GB expensive. Didn't IT industry long time ago accepted that the most economical way (for most applications) is that we have multiple layers of memory: from very fast and expensive CPU registers, to CPU cache, to RAM, to disk ? http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment64http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment64Fri, 22 Oct 2010 19:13:18 GMTDouble fail: MySQL doesn't store the column names with every row. http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment63http://ayende.com/4669/you-saved-5-cents-and-your-code-is-not-readable-congrats#comment63Fri, 22 Oct 2010 19:10:31 GMT