I re-ran some tests using the StopWatch class to hard code some metrics into the application and they also confirmed the findings. What’s up? How could a class that everyone says you can use to your hearts content when it came to string concatenation was failing me?

Turns out, it was a mix of misuse and a common misconception about the StringBuilder Class.

One of the first things you learn while picking up .NET is that the StringBuilder Class is your friend when it comes to concatenating large strings in memory. It beats the pants off of String.Concat and String.Format, while also being a mutable object in the Framework utilizing an in-memory buffer.

I used JetBrains dotTrace to help profile the application and it was very evident from the get-go that StringBuilder was causing the whole process to slow down.

The nature of my application was basically reading in a text buffer 1 character as a time, and using the StringBuilder as an output buffer. So for a 1k file, The method Append(char) would be called 1024 times. A 600k file would call Append(char) 614,400 times.

So why was I getting burned in execution time? The issue turned out to be two fold.

First, there’s overhead cost to the call. I don’t care how lightweight your method is, if you’re calling it SIX HUNDRED THOUSAND TIMES, it’s going to take a bit. Let alone a method who handles a string buffer in memory and string manipulation. So basically, no matter how fast StringBuilder actually is, it’s not a free call and you should consider the fact that the call still has overhead when architecting your solution.

Architecture brings me to my second point. While writing each character individually made sense initally, it seems that it was just lazy The optimized route would have been calling Append with a SUBSTRING of the input buffer, this way we avoid the overhead of multiple calls by writing all the neccisary data in one big blob.

So 600,000 calls to StringBuilder.Append(char) becomes only a few hundred calls to StringBuilder.Append(string.Substring(start, count)). Sure, the Substring Virtual Method itself has overhead, but it’s still less than the thousands of calls to Append(char) that we’re saving ourself

Conclusion?

StringBuilder is fast, but it’s not free. Take this into consideration when utilizing it while appending large data sets in small chunks.

Cheers!

This version of WWWinamp requires that you have the Microsoft .NET Framework 3.5 installed. You can get this from Microsoft.com by clicking here.

I’m calling it beta because a -lot- has changed behind the scenes and I did my best to test every feature but I might have missed a few bugs here and there. If you’re not comfortable running unstable version of software, then I suggest you install the previous release of WWWinamp v4.1 Build 2809. You can get it from here.

What’s new in this version of WWWinamp?

• [HTTP] Recoded processing of inbound HTTP Requests
• [HTTP] Fixed Defect #46: Processing HTTP Auth header even if one isn’t present
• [WCF] Small Optimizations
• Requires Microsoft .NET Framework 3.5
• Autoupdate Checks for new release on startup of WWWinamp (can be disabled in config)
• Minor UI Fixes

This version of WWWinamp is mostly a code cleanup and conversion to the .NET Framework 3.5. The source code now weighs in at a 300+ lines of code lighter than the previous version, while still maintaining the same functionality. I’m currently working on a Silverlight skin for WWWinamp which interfaces with the WCF endpoint for greater control and seamless use. Expect that to be out in the next month or so… well, perhaps longer I’m not too good with graphics and UI stuff, so I’ll do the best I can.

I also took the time and added a lot of comments to the WWWinamp CONFIG file. This should help users figure out what each configuration option means and their different settings. Hopefully this should help lower the amount of e-Mail I get from people who are getting errors because WWWinamp isn’t configured properly

Again, this is a BETA version and might not work 100% properly… it could have some personality But I believe it’s stable enough for release.

Share and enjoy!

WWWinamp v4.2 Build 2948 – Download (56k)

I’m currently working on the latest version of WWWinamp after taking another hiatus from the project in order to clear my head and work on some other fun things such as the previously mentioned XNA projects

The next version of WWWinamp will be targeted for the .NET 3.5 Framework and you will need to have it installed on your machine in order to run WWWinamp. Most of the changes in this version are behind the scenes and will probably be transparent to you, the user. BUT, some visible changes in the upcoming version of WWWinamp 4.2 will be:

• Automatic Version Checking for new releases of WWWinamp
• Ability to enable or disable Automatic Version Checking
• Ability to enable or disable Windows Vista warning message
  
• Improved performance under load

I know, nothing earth shattering on the horizon. “Why is this?” you might as. Well, the honest reason is that I haven’t received any bug reports with issues that weren’t related to a misconfiguration or user error. This is a good thing! It means that WWWinamp is stable and there aren’t any horrible bugs that continue to nag users. The downside to this is that because WWWinamp is pretty feature rich as is, I’m running low on ideas that could be implemented.

An idea I’ve tossed about and am thinking about trying out is creating a WWWinamp .NET assembly for user within your own Windows or ASP.NET applications developed using the .NET framework. The assembly would handle the media library and searching of the library so you wouldn’t have to code your own database and file searching routines, as well as handling the unmanaged code required to interface with Winamp (if it’s running locally on the WWWinamp machine) or communicating via WCF to a remote instance of WWWinamp running the WCF daemon.

I think that between the WWWinamp Server and my proposed WWWinamp Assembly, that’d give both advanced and novice users full control over their setup.

As I mentioned in a previous post, I’ve moved WWWinamp into Visual Studio 2008 with Team Foundation Server. Within the latest version of Visual Studio 2008 there is a set of code analysis tools which calculate such items as Code Maintainability and Cyclomatic Complexity. I ran it on WWWinamp and it scored the following:

Maintainability Index: 83 (out of 100)

Cyclomatic Complexity: 636

Depth of Inheritance: 7

Class Coupling: 151

Lines of Code: 1,829 (!!)

After over a year, I think WWWinamp has gotten better and continues to improve with every version!

Big thanks to everyone for their support and keep your eyes peeled here for the latest version of WWWinamp!

I thought I’d post a small update on what’s going on in my little world as well as the status of WWWinamp and other associated projects.

I hope that everyone is enjoying WWWinamp and the work I’ve put into it! I enjoy providing it as much as I love hearing from my users. So please, if you have any feedback or questions, send them to WWWINAMP ATnospam ENUSBAUM.COM (you know what I mean). I try to reply to each user request as quickly as time allows.

So where do things stand? Well, things have been at a bit of a stand still for the last month or so. On top of my wife and I moving into a new place, we were also impacted by the wildfires that swept through San Diego county in October. Because of this, I haven’t been able to dedicate too much time to development projects.

Now that things are starting to settle back down, I’ve picked up the code base and started to tinker away once again. I’m currently working on a WWWinamp WPF XBAP using XAML. Lots of acronyms, I know. But basically it’ll be as if you’re running WinAmp within the browser, and then have that browser copy of WinAmp control WWWinamp using it’s WCF endpoint. This would be another real world use of the WCF endpoint.

I know some people use Mac as well (I’m included, I’ve been using my PowerPC Notebook now for a couple years), so I’m going to try to write a class or two using Coaca and Objective-C to interface with the WCF endpoint in WWWinamp using SOAP. This way, it might be possble to write native OSX applications that can also control WWWinamp remotely.

So anyways, that’s a quick status update. I hope to have an updated build of WWWinamp out by the end of next week which will include some bug fixes and a couple new features which are from the v3.0 branch. These are being added at the request of user e-Mails. So keep ‘em coming!

Cheers!

This is WWWinamp’s friendly way of saying that you do not have the Microsoft .NET Framework v3.0 installed. You can download it from Microsoft here.

Cheers!

This update adds support for the new WWWinampGetStatus() method. This method was added so the WCF could could easily access information on WinAmp and WWWinamp including the current configuration values.
Supported values:

• CommandName
• “CURRENT_SONG”
• CommandValue
• “TITLE” – Returns Title of Current Song
• “NUMBER” – Returns Playlist Number or Current Song
• “BITRATE” – Returns Bitrate of Current Song
• “SAMPLERATE” – Returns Sample Rate of Current Song
• “LENGTH” – Returns Length of Current Song (in Milliseconds)
• “ELAPSED” – Returns Elapsed Time of current Song (in Milliseconds, -1 if Stopped)
• “STATUS” – Returns Playing Status of Current Song (Playing, Paused, Stopped)
• “LIBRARY”
• CommandValue
• “SIZE” – Returns the size of the Library (Number of Files)
• “PLAYLIST”
• CommandValue
• “SIZE” – Returns the size of the Playlist (Number or Files)
• “POSITION” – Returns the current position of WinAmp in the Playlist
• “CONFIG”
• CommandValue
• WWWinamp Config Value Defined in WWWinamp.config (i.e. “WWWinamp.Media.HomeDirectory”)

Please let me know if you encounter any errors while testing this new method!

Cheers!

WWWinamp WCF Client Example for WWWinamp Build 2809 – Download (14k)

The latest build of WWWinamp is good to go. I’ve been trying to expand out the WCF Endpoint to include as much information to the client as possible. This should allow a remote application access to every resource that WWWinamp has available locally.

WWWinamp v4.1 Build 2809 includes the following fixes/changes:

• [WCF] Added WWWinampGetStatus() Method to retrieve information on WinAmp and the current file
• [HTTP] Fixed script parsing issue when a file contained multiple HTML comment tags
• [HTTP] Added optional Google AdWords to help support program
• Minor UI Fixes

One of the small changes to this version is a small Google AdWords banner on the playlist screen. This is an optional script tag which can be removed. Leaving in this small banner will help support WWWinamp.

I’m also going to release an updated WWWinamp WCF Client Example program which includes the additional functionality which is included in Build 2809.

Again, I ask users of WWWinamp to submit their Error Logs so we can make WWWinamp a better product!
Cheers!

WWWinamp v4.1 Build 2809 – Download (57k)

UPDATE: The new WCF Example Client can be found here. It includes examples on how to use the new method WWWinampGetStatus() as well as a few bug fixes. The C# source code for this example is provided. For development environment prerequisites and setup help, please read this post.

Bugs fixed in Build 2800 are:

• Fixed error when trying to generate playlist when the playlist was empty
• Fixed error when trying to generate playlist and winamp.m3u can’t be found

I’m working on getting the WinAmp Status script tags worked into the WCF endpoint. They should be ready to rock with the next release.

WWWinamp v4.1 Build 2800 – Download (55k)

Cheers!

• Microsoft Visual Studio 2005 with SP1
• Microsoft .NET Framework 3.0 (link)
• Visual Studio 2005 extensions for .NET Framework 3.0 (link)

Once you load up the C# project in visual studio, you need to make a couple updates to the URI’s used to access the service:

1. Start WWWinamp and start the WCF Service. Make note of the URI that WWWinamp displays, as this is the URI that your WCF client will need to connect to. It will look like the following:
• WCF Service Started at http://10.0.1.212:8080/WCFService
2. Update the URI’s that are listed in WWWinampWCF.map and app.config
• These files are located:
• 
• The values you need to update in WWWinampWCF.map are:
• ServiceReferenceURI
• Address
• The value you need to update in app.config is:
• Address

Once you’ve updated the Service URI references, you should be able to launch the Example Client.

The WCF password that is used to secure the WCF Endpoint in WWWinamp is stored in the WWWinamp.config file under the option WWWinamp.WCF.Authentication. Enter this password in the “WCF Password” field and you should be able to communicate with WWWinamp now using WCF!

Using this example, you can create your own ‘frontend’ for WWWinamp using C#, VB.NET, Java, JSP, you name it!

If you have any questions about the WCF endpoint or bugs that you run into during your development, please let me know!

Cheers!

WWWinamp WCF Client Example – Download (14k)

So I’ll just keep updates of v4.1 isolated to my little blog here until I feel it’s ready to take it’s rightful place on the front page.

There are a couple changes I think users should take note of before installing this new version of WWWinamp:

1. The new .CONFIG file for storing WWWinamp configuration options
• This new file is used to store the configuration options that were previously kept within the WWWinamp.XML file. I’ve moved the options to this file as to utilize the built in Application Configuration Manager native to .NET and replace the custom XML parser I was using to load the options. This allows me better control and error handling when perhaps an invalid option is found or one is completely missing. I’ve tried to keep the configuration VALUES the same, but even so, please use caution when copying your configuration options over from the previous WWWinamp.xml file.
2. The .MANIFEST file included with WWWinamp
• This file allows WWWinamp to run as Administrator in Windows Vista. It will cause Vista to prompt that WWWinamp would like to run as Administrator. I’ve left this as an optional file for now. I’ll see how you guys like it before I sign the EXE with the manifest making it permanently part of the program. If you do not like WWWinamp running as administrator, just delete the file. WWWinamp has to be running as Administrator in Windows Vista for the WCF endpoint to work.
3. THE MICROSOFT .NET FRAMEWORK 3.0 IS NOW REQUIRED
• The .NET 3.0 Framework is now required to run WWWinamp. This is due to the addition of WCF support. I’m sure users will piss and moan about this, but too bad. WCF was too sweet of an addition not to include only because some people refuse to live in the now

I’m sure you’ll find some few new things here or there to play with. Please submit any errors as you get them by simply e-Mailing me your error.log file.
Cheers!

WWWinamp v4.1 Build 2793 – Download (56k)