Stop Coding!

The Unofficial Flex Compiler Blog

A New Version of HFCD

with 8 comments

Recently I picked up the hfcd project again and finally added features that I promised last year. Yes, it’s a new version of hfcd. This morning, I’ve finished testing what I got so far. It’s in beta quality, but I think I should release it so you folks can give it a spin and give me some feedback.

Let me give a brief intro of what hfcd is. HellFire Compiler Daemon is a RPC-style Flex Compiler server. Clients use the Flex Compiler API to communicate with hfcd. Basically, client processes use hfcd to compile Flex applications. The most obvious client is Flex Builder 3. FB3, by using the hfcd client SDK, can offload compilations to hfcd so that its memory and CPU resources can be reserved for other FB3 popular tasks: design view, code model, profiling, just to name a few. The result is dramatic. hfcd compiles Flex applications much faster in most cases than compiling apps in-memory with FB3.

The hfcd version I released last year was an proof-of-concept attempt. One limitation was that it had to run locally with FB3 (i.e. on the same machine). Now, with the new features recently added to hfcd, it’s able to run on a remote machine. This implies that if the remote machine has more memory and faster processors, the build time could be dramatically reduced. This is certainly one option of improving the compiler performance.

Furthermore, I added the following features:

  1. hfcd supports a virtual file system that holds source files in memory. It means your hfcd server machine will never be littered with codes from many different sources.
  2. hfcd supports background compilations, both full and incremental. This is a game changer. Why? Developers usually edit multiple files before they build (Ctrl-B) and test. As long as developers save changes continuously (instead of keeping all the changes to the one-and-only Ctrl-S), the background compilation could kick in and compile some changes while developers are making the rest of the changes. The result, developers wait much shorter incremental build time after the last Ctrl-S and Ctrl-B.
  3. hfcd takes advantage of multi-processor-core technology wherever possible. It attempts to build applications and libraries that have no mutual dependencies simultaneously. For example, if you have 2 SWC projects and 3 SWF projects. The SWC projects don’t depend on each other. With FB3, your build time would be: T(SWC1 + SWC2 + SWF1 + SWF2 + SWF3). With FB3 + hfcd, your build time would be roughly: T(max(SWC1, SWC2) + max(SWF1, SWF2, SWF3))! Another game changer!

The currently supported SDK version is 3.3.0.4852. I hope to add support for 3.4.0 in the near term. UPDATE (Nov 25th, 2009): Now HFCD supports Flex SDK 3.4.1 and 4.0.0.

In the next few weeks, I need some developers to test my first beta. If you are interested, please email hfcd@stopcoding.org. This weekend, I hope to get a web page ready so you folks can register and download there.

Advertisements

Written by Clement Wong

September 25, 2009 at 2:40 pm

8 Responses

Subscribe to comments with RSS.

  1. This is great. I have been waiting for an update on hfcd for a while and this new update definitely seems very promising.

    venkat

    September 25, 2009 at 4:04 pm

  2. That’s pretty awesome. I am working with 10 different swc projects compiling all the time and flex compilation has been area of frustration for me. My core 2 duo 3GHz is 100% nearly all the time. I certainly would like to give it a try.

    Myo

    September 27, 2009 at 12:49 am

  3. I’m ready to test it 😉
    give me a link

    Matteo

    September 27, 2009 at 9:13 am

  4. […] Builder, Flex Compiler, Flex Compiler API, HellFire Compiler Daemon, hfcd In my first blog post (A New Version of HFCD) of this year, I mentioned that the latest version of HFCD, currently in beta, supports […]

  5. What about implementing HFCD so that it could run as a servlet, and you could submit MXML or AS to it, and it would give you back a SWF or SWC on the fly…or place it on the server somewhere you specify?

    Rick Bullotta

    October 30, 2009 at 4:21 pm

    • It’s doable. Skipping the deployment step is also a nice idea. Let me think about it…

      Clement Wong

      November 16, 2009 at 9:13 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: