RSS feed for InstantSpot site EdomGroup Blog

ColdFusion Flash Forms To Flex 2

Sat, 01 Jul 2006 16:39:29 GMT

I'll start off by saying that when Macromedia (when they were still Macromedia) released CFMX 7, it was truly amazing. CFMX 7 has a feature set that I have not seen another application server come close to matching; Flash forms, pdf generation, XForms, gateways, and the list goes on. What was equally amazing was the extent to which the CF community took these features and ran with them. The ASFusion group did things with Flash forms people thought were impossible. Todd, at cfsilence.com developed a data source browser, called Genesis, that connects to your CF server and allowed you to run SQL against the data sources. All these things have really helped push ColdFusion as a valuable resource for web application development. Now Adobe, since aquiring Macromedia, has gone and done it again by releasing the Flex 2 SDK for free. The demos are insane and whats more is that now every website, running ColdFusion or not, can have rich Flash content - that cool admin control panel, or the great shopping cart.

So with all the giving from Adobe and the CF community going around I decided to post the Ant build script I wrote for automatically compiling Flex 2 applications from within Eclipse.

To use the script:

copy the source into a build.xml file in your project folder
edit the properties at the top of the file to point to your sdk install directory, debug flash player, the input mxml file and the output swf file
right click the file and choose "Run As" > "External Tools"
create two new "Ant Build" configurations, one called "build" and the other called "run"
now in the targets tab of the build configuration make sure only the build target is checked
in the targets tab of the run configuration make sure only the run target is checked

Once the setup is done you can run the build commands using the 'Alt+Shift+x q' shortcut.

<?xml version="1.0"?>
<project name="Flex2 build script" default="build" basedir=".">
   <property name="installdir" value="/Flex2SDK"/>
   <property name="libdir" value="${installdir}/lib"/>
   <property name="mxmlc" value="${libdir}/mxmlc.jar"/>

   <property name="src" location="customer.mxml"/>
   <property name="swf" location="customer.swf"/>
   <property name="player" location="${installdir}/player/debug/SAFlashPlayer.exe"/>

   <target name="init">
   </target>

   <target name="build" depends="init">
      <antcall target="compile"/>
   </target>

   <target name="compile">
      <java jar="${mxmlc}" fork="true" failonerror="true">
         <classpath>
            <fileset dir="${libdir}">
               <include name="**/*.jar"/>
            </fileset>
         </classpath>
         <jvmarg value="-Dapplication.home=${installdir}"/>
         <jvmarg value="-ea"/>
         <jvmarg value="-DAS3"/>
         <jvmarg value="-DAVMPLUS"/>
         <jvmarg value="-Xms32m"/>
         <jvmarg value="-Xmx756m"/>
         <jvmarg value="-Dsun.io.useCanonCaches=false"/>
         <arg value="-incremental"/>
         <arg file="${src}"/>
      </java>
   </target>

   <target name="run">
      <exec executable="${player}" dir="${basedir}" spawn="true">
         <arg value="${swf}"/>
      </exec>
   </target>

</project>

Java performance analysis - a real life example

Fri, 02 Jun 2006 03:43:25 GMT

For my thesis I'm writing a Java program that parses two text files (representing satellite images) and performs some analysis on them. The two files are 128 MB and each was taking ~33 seconds to parse. The analysis takes only a fraction of that time, then the results are written back to an output file.

Thinking this was very slow, since the files should be pretty much sequential access off the disk and the read-ahead-buffer would have cached the next block, I decided to dig a little. I rewrote the parsing algorithm in C since it's easier to manage the low-level IO. I used the file stream functions (fopen,fread,fclose) provided by stdio. When I ran the program it took ~10 seconds.

This was insane. Java does have more overhead due to its garbage collection, HotSpot optimizer, and object memory management but it should not be a magnitude of 3x slower. After a few minutes looking at the Java implementation I realized I had forgotten to instantiate a BufferedReader. I immediately jumped to the documentation and there it was, each call to the read method of the FileReader blocks until data is available. If no BufferedReader is supplied this means a context switch for each call. No wonder Java was taking so long. Adding the buffering I reran the algorithm and wow, 13 seconds. Not to bad for a “boated” language.

Figuring I had more places in my program which could be optimized I began looking. The first place I went was to one of the main methods, the one which did the analysis on each image. The logic was pretty simple, find the next pattern in the given image, see if it exists in a lookup table, if so update its statistics or create a new key and add it as a new entry. The data structure I was using for the lookup table was a simple HashMap object. When writing that section of the program I was still relatively new to the Java language and just went with what I'd used in other languages, an associative array.

I did a little analysis with some System.out.println statements and found that on average there was a 14,000 : 15 ratio between reads and writes on the lookup table. Knowing this ratio was pretty stable (I wasn't going to get anywhere near 50% writes) I decided a better data structure would be something with read time of O(n) or less, instead of O(h(k)) where h(k) was the hash function on the key. This meant an array would be best, but I didn't want the hassle of managing the size of the array as new patterns where found. Java had to have something for this. After a little searching I found java.util.concurrent.CopyOnWriteArrayList. This was exactly what I needed. After a little tweaking the new code ran in 1/3 the time.

After this I wrote some small timed programs to examine the running time of the HashMap data structure and the CopyOnWriteArrayList. What I found was as the mutations approached 25% the CopyOnWriteArrayList's performance slowed at an exponential rate. Finally, I couldn't evaluate the performance because the tests were taking too long. On the other hand, the HashMap data structure had a fairly constant performance time irrelevant on the read/write ratio.