ItDepends: Code Dependency Analysis For Flex/AIR Applications
March 26, 2008 on 5:56 pm | In Flex, Programming |I’m pleased to be able to release a new open source tool to the Flex development community today, that comes out our work at Allurent. The tool is called ItDepends and is located on Google Code. It analyzes the dependencies between classes in a Flex application, using a link report generated by the Flex compiler, and shows this information in an easy-to-use visual browser UI. ItDepends can show you what classes and packages take up the most room in your application and how they depend on each other. It can also show you what results you might achieve by removing classes or partitioning your code into modules, without having to redesign or recompile your application.
It’s written in Adobe AIR of course! I find AIR a nice, productive environment for creating UI-driven tools quickly and easily.
Here are some screen shots. Please see the ItDepends project wiki for more information, and please do download the app and try it out. The UI is kind of clunky, as this tool was kind of a quick hack, but it does get the job done.
8 Comments »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Entries and comments feeds.
Valid XHTML and CSS.
All content copyright (c) 2006-2007 Joseph Berkovitz. All Rights Reserved.
Neat little app. I never knew the Flex compiler could spit out so much information.
Comment by Rex Sheridan — March 26, 2008 #
Bad ass!!!
Comment by JesterXL — March 26, 2008 #
Awesome - a great contribution to the community.
One of the issues I occasionally run into when porting code is a dependency on a class that may only be referenced in a string. For example, a dataTipRenderer for a chart. Does your application locate those dependencies as well?
Comment by Tom Lee — March 28, 2008 #
No, the compiler (and hence ItDepends) has no idea if you are using getDefinitionByName() to find your classes. On the other hand, your renderer class wouldn’t be linked into the app if there wasn’t some compile-time dependency somewhere.
Comment by joe — March 28, 2008 #
Are you getting the sizes directly from the link report (I cannot imagine where else you get them from)? I wrote a very similar tool to try to do framework optimization (I can share it with you offline), but found that the numbers in the report are pretty much useless except as extremely high upper bounds.
For one, they are unoptimized (I forget if I committed an update to the link report which spits out a slightly optimized value as well). The biggest issue is that they don’t take into account the constant pool — if 100 strings are shared between two classes, each class will report that they take up the space of 100 strings, and the size changes between compiles depending on other factors.
I find the link report most useful to track new and removed dependencies. I should probably open-source my diff tool.
Comment by Jono — April 2, 2008 #
Yes, Jono, I am getting the sizes directly from the link report. At the time I wrote it I didn’t have access to the compiler. Now that I do, it should be possible to get much more exact numbers by instrumenting the bytecode emitter and global optimizer. But I’ve found that exact numbers are not really important — it’s more a question of where the “center of gravity” lies in the app.
Although the numbers are not correct in absolute terms (generally they are inflated by a factor of 6 or so), they are quite useful as a proportional measure of where the code size lies in the app. In typical Flex apps, shared constants do not seem to take up a very large portion of the code.
ItDepends does in fact have the same diff capability built into it — if you create a child module window from the main app window, and drag app classes into the module, all the dependencies removed from the main app will travel into the module.
In the meantime ItDepends does have a crude ability to read the output dumps from the SwfxPrinter tool and map the printed function names back into the classes they come from. Those code sizes are super accurate but of course there is no dependency info there.
Comment by joe — April 2, 2008 #
It doesn’t seem to work properly for generated classes. For example, I look at mx.skins.halo.HaloBorder and it says it’s referred to by nothing, which doesn’t make much sense. However, if you look at _globalStyle (atleast in my case), you’ll see that ItDepends correctly reports that it refers to mx.skins.halo.HaloBorder.
Comment by Ryan — April 8, 2008 #
Ryan — can you please create a bug on Google Code and attach your link report so I can try to reproduce the bug? Thanks!
Comment by joe — April 8, 2008 #