Linked by Thom Holwerda on Sat 11th May 2013 21:41 UTC
Windows "Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening." That's one way to start an insider explanation of why Windows' performance isn't up to snuff. Written by someone who actually contributes code to the Windows NT kernel, the comment on Hacker News, later deleted but reposted with permission on Marc Bevand's blog, paints a very dreary picture of the state of Windows development. The root issue? Think of how Linux is developed, and you'll know the answer.
Permalink for comment 561619
To read all comments associated with this story, please click here.
RE[15]: Too funny
by Alfman on Wed 15th May 2013 03:18 UTC in reply to "RE[14]: Too funny"
Member since:


"Again, no issues that other formats don't face. However, you are mistaken about something. You don't have to lock a file for reading; ever. grep/sed/awk will always work even if a database is currently using a file. The only time you need to lock files is when you're writing (and that only blocks writers.)"

The difference is that normally databases aren't designed to have their datastores read/written by external processes as they're being used, so the problem doesn't really come up at all. Never the less I do want to point out that even for textual databases readers do need to be blocked and/or intercepted in order to prevent incomplete writes & incomplete transactions from being seen by the reader.

If you don't have a database background, you might not realize that transactions can involve many non-contiguous records such that without locking you'd end up with a race condition between the reader / writer starting and completing their work in the wrong order.

"I've had issues where MS SQL Server doesn't delete rows from a table, but they also don't show up in queries... (they did appear in Management Studio though.)"

It's not a bug, it's a feature ;)

In the absence of a confirmed bug report, my gut feeling is that the most likely cause of your problem was an uncommitted transaction. Maybe you deleted and queried the result *inside* one transaction, then from another program you still saw the original records. You wouldn't see the deletions until the first transaction was committed. This can surprise you if you aren't expecting it, but it makes sense once you think about it.

When you program in pl/sql, for example, by default all the changes you make (across many datatables and even schemas) remain uncommitted. You can execute one or more pl/sql programs & update statements from your IDE and then query the results, but until you hit the commit button, noone else can see your changes. The semantics of SQL guarantee that all those changes are committed atomically. It's understandable that awareness of these SQL concepts is low outside the realm of SQL practitioners given that they don't exist in conventional file systems nor programming languages.

"I mean, I haven't been saying 'don't use SQL' or 'the relational model sucks!' I've been saying 'I want to be able to read my log files with any old tool, but adding in a query engine would be cool too.' The only issue that could arise with what I want is performance. And not only do I think log files aren't likely to have this issue; but I think that it can be solved without abandoning text."

The thing is, if your software supports logging into a database interface, you could have a simple NULL database engine that does absolutely nothing except output a text record into a text file. That's essentially a freebee for you.

The inverse is not true, processes that are developed to output to text files will need additional external scripts/jobs for parsing and inserting relational records into the database. Also there's a very real risk that the logging program will not log enough information to maintain full relational integrity because it wasn't designed with that use case in mind. Our after-the-fact import scripts are sometimes left to fuzzy matching records based on timestamps or whatnot. If the standard logging conventions dictated that programs used a structured database record format from the get go, such ambiguities wouldn't have arisen.

It's probably wishful thinking that all programs could shift to more structured logging at this point since we're already entrenched in the current way of doing things. But if we had it all to do over, it would make a lot of sense to give modern database concepts a more prominent primary role in our everyday operating systems.

Edited 2013-05-15 03:22 UTC

Reply Parent Score: 2