14

A server application pulled off some sort of listings as table. Problem was, it crashed with some thousand data files after one and a half hours. I looked into that, and couldn't stop WTFing.

A stupid server side script fetched the data in XML (WTF!) and then inserted shit node-wise (WTF!!), which was O(n^2) - in PHP and on XML! Then it converted the whole shebang into HTML for browser display although users would finally copy/paste the result into Excel anyway.

The original developer even had written a note on the application page that pulling the data "could take long". Yeah because it's so fucking STUPID that Clippy is an Einstein in comparison, that's why!

So I pulled the raw data via batch file without XML wrapping and wrote a little C program for merging the dumped stuff client-side in O(n), spitting out a final CSV for Excel import.

Instead of fucking the server for 1.5 hours and then crashing, shit is done after 7 seconds, out of which the actual data processing takes 40 bloody milliseconds!

Comments
  • 3
    That's some next-level inefficiency.. if you ever get to know who made that atrocity, please kick them in the nuts so that they can't reproduce _/\_
  • 3
    Might be management requirements too... I have done this kind of thing in the past "a HTML table" that I figured out later that moron copied to an excel file... Such a face palm when I saw her copying it to excel that I could not say anything I just let it be.
  • 3
    @hell in this case, the browser display in itself isn't really useful. The intended workflow necessarily goes over to MS Office afterwards. The copy/paste step even takes more time with a lot of data, plus that importing CSV is more reliable.

    That's why the HTML display was nonsense from the get-go. It just seemed the easiest way for the glue code hacker back then.
  • 2
    @Condor he isn't there anymore. But back then, he was the one who hired me.. LOL!
Add Comment