C# Practice Makes Perfect

A simple fix cured the image sync issue, but in this case the fixer couldn't berate the pup who made the error.

For years, nobody cared that the legacy image-syncing application consumed as much bandwidth and processing time as it did.

Sure, it took 18 hours to sync 90,000 images, but considering the volume, how could anyone complain? Compared to a lot of other buggy enterprise-level applications in the organization, it was a tank.

After years of running under the radar, a server performance audit found that the "tank" didn't play nicely with system resources in its shared environment. The auditors' verdict: Unless someone was willing to switch what should've been a simple process to run on a costly dedicated server, the software performance needed to be fixed, ASAP.

Assigned to investigate and fix the problem, Jeff dove in.

Command-Line Console
Written as an intern's "learning .NET" project years earlier, the "tank" was a C#-based console application. It connected to a SQL Server database to retrieve a data set of content IDs and image URLs, and then fetched a bunch of JPG files.

Finding the logic -- along with the culprit code -- couldn't have been easier:

DataTableReader dtReader = img.CreateDataReader();
while (dtReader.Read())
    Console.WriteLine("Link " + dtReader["'id"] + ": " + dtReader["link"]);
    DataRow[] dataRow = dataimg.Where(x => x.columnXYZ == dtReader["id"]);
      string test = dataRow[0]["link"].ToString();
    catch (IndexOutOfRangeException exaa)
      if (String.Compare(dtReader["link"].ToString().Trim(), "") == 1)
         comand = "C:\\tools\\curl\\curl.exe -k -H " + 
                   "\"Content-Type: image/jpg\" " + dtReader["link"] + 
                   " > " + Dpf1 + dtReader["id"] + ".jpg";
         StreamWriter myFile1 = new StreamWriter(fname1);

      Process getContentZIP = new Process();
      getContentZIP.StartInfo.FileName = @"x:\path\to\xyz.cmd";
      getContentZIP.StartInfo.WorkingDirectory = @"x:\path";
      getContentZIP.StartInfo.CreateNoWindow = false;

Temporarily ignoring the obvious quirks in the code, Jeff discovered that an error in a different section of the program ensured that the exception was always caught, resulting in its poor performance.

Spotty Execution
Hoping to stave off the auditors in the short term, Jeff made a quick fix so that the exception logic only executed when new or updated images needed to be fetched (instead of every time). This reduced the runtime to a fraction of what it originally was, much to the delight of the auditors and managers alike.

With the development out of the way, Jeff's most difficult task of all remained: He had to convince his coworkers that the intern who originally authored the C# console application -- who also happened to be named Jeff and coincidentally shared his last name -- wasn't him.

About the Author

Mark Bowytz is a contributor to the popular Web site The Daily WTF. He has more than a decade of IT experience and is currently a systems analyst for PPG Industries.

comments powered by Disqus


Subscribe on YouTube