why do my modules keep getting rebuilt - apache-flex

I have a flex project, which has a main application, and then a number of small modules (17 of them).
For reasons I have not been able to figure out, when I do a 'debug-compile' to test, frequently (but not always), it decides to rebuild the modules, though, nothing within the modules has changed in any way. Without the modules re-compiling, it takes about 5 seconds to build the app, but with it, it's upwards of 2 minutes.
I assume its that something the modules all need is getting changed, but for the life of me, I can't figure it out.
How can I resolve this?

the FlashBuilder compiler I find has some terrible linking issues... I highly recommend looking at HFCD - HellFire Compiler Daemon. It is an out-of-process multi-threaded mxml compiler that quite frankly just kicks some serious ass. We saw our compile times drop astronomically for us, though our project is friggin huge. Additionally since the compiling is not happening inside flash builder, flash builder is far more responsive now.
http://stopcoding.wordpress.com/2009/10/20/hfcd-pick-your-compiler-speed-how-about-10x/

Related

Do you have any suggestions on how to speed up precompiling a Kentico site? AKA: the aspnet_compiler is VERY slow

I have a Kentico 6 site that we have squeezed better performance out of by precompiling. We have a Team City Continuous Integration (CI) server that runs the build automatically on check in to the subversion repository.
However, the build takes 40 min! About 33 min are during the aspnet_compiler step! This is a pretty long time for a build that SHOULD take less than 10 min. I've gone through some of the various perf improvements such as moving the asp.temp files to a fast SSD. During the aspnet_compiler step, the server is using very little CPU, Disk and RAM. The CPU use seems to avg about 1%! In researching about aspnet_compiler, I have found many pages complaining about the speed, but a dramatic silence from Microsoft about it.
https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/4417181-speed-up-the-aspnet-compiler http://programminglife.wordpress.com/2009/04/16/aspnet_compiler-compilation-speed-part-1/
I've come to (perhaps erroneous) conclusion that if I can't speed up the aspnet_compiler, then perhaps I can reduce it's workload. Since Kentico has lots of controls in the project, are there any savings that I can glean by remove extraneous controls? ie: if I run the aspnet_compiler for a project with a single page, it's quick.
I've also thought about maybe making the cmsdesk a separate application that only needs to be compiled after a new hotfix has been applied.
To recap: My two concerns are: #1 - can I speed up the aspnet_compiler somehow? #2 - If I can't, then I'm guessing I can reduce it's workload.
In relation to #1, maybe I can do incremental compilation, so that I only precompile files that have changed since the last build? I haven't found much info about doing this; there are a few unanswered questions on StackOverflow about this very topic - eg: aspnet_compiler incremental precompile Incremental Build aspnet_compiler
FYI - for those of you unfamiliar with Kentico CMS, It's a Web Site Project, with LOTS of controls - maybe hundreds of them.
Any ideas?
PS - I have a reply on the Kentico forums: http://devnet.kentico.com/questions/do-you-have-any-suggestions-on-how-to-speed-up-precompiling-a-kentico-site-aka-the-aspnet_compiler-is-really-slow
One thing our team did try to improve the compilation time was to remove the modules and set of controls that were not necessary to the project(forum, ecommerce etc..) to speed up the compilation time.
Also, which approach do you use for developement, portals or aspx? as we've noticed that compilation prove to be faster in the portal approach than in the ASPX .
Everything I've read says that precompiling with aspnet_compiler is super difficult to achieve with Kentico.
However, I managed to find this post on Kentico's forums where someone appears to have figured out a way to make your system work for them (search for EHUGGINS-PINNACLEOFINDIANA on the page and you'll find it).
I have heard that using MSDeploy or MSBuild are a much more efficient way to precompile than directly calling aspnet_compiler (although I'm pretty sure both of those either still call aspnet_compiler or do the same thing it does, only faster).
I've personally never tried using any of these methods (and I'm pretty new to ASP.NET myself), but I figured I could at least give you some leads:
http://odetocode.com/blogs/scott/archive/2006/10/18/what-can-aspnet_compiler-exe-do-for-me.aspx
http://therightstuff.de/2010/02/06/How-We-Practice-Continuous-Integration-And-Deployment-With-MSDeploy.aspx
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html

Fast alternative to Flash Builder

I have a large application in Flex.
I use Flash Builder to develop it. Flash Builder works good, until I attempt to compile my project.
It takes too much time to check small changes of application interface.
Is there faster alternative to Flash Builder? Does InelliJ Idea compile large projects faster?
I need to check just one interface panel out of 100, is there any solution that would allow to preview just it (except dividing application into smaller modules)?
FDT and IntelliJ Idea both use the default compiler that is shipped with the SDK for the version of Flex that you use. I would assume that Flash Builder does the same, but I currently have never used this product. I know that FDT will compile a relatively large program quickly by only compiling those thing that have changed since the last compile, which is an option for IntelliJ as well.
Before abandoning your current IDE I would check to make sure this is not an option in it as well, I know that if I go from FDT to FlashDevelop or IntelliJ there are several little things that seem to show up in the IDE. None are really errors, but have to be taken care of prior to a compile to keep things tidy.
If you decide that a change in IDE is a must, I can vouch for any of the above as solid software to work in, with FDT being my current favorite as it has the tools that I use the most.

Recent Step-by-Step for ActionScript / Flex / AIR with TextMate?

i apologize if this post is redundant.
i'm searching unsuccessfully for recent, step-by-step instructions on how to set up ActionScript 3, Flex 4.5 and AIR 2.6 with TextMate on Mac OS X.
i've found several posts concerning required bundles, but most of the threads are a few years old in addition to having convoluted, sparse instructions for setting up.
it seems that auto-complete and .swc files are supported, which is great. in addition to instructions i'm also very interested in learning about what isn't supported and other common pitfalls.
i've been familiarizing myself with TextMate's UI and it's amazing. i would much rather use it than Flash Builder / Eclipse, or even Flash Professional.
one last question - i understand that it's possible to set up our own keyboard shortcuts to compile with MXMLC and write the .swf to disk. is it possible to have the .swf auto open in Flash Player Debugger after it is compiled. essentially, i'd like to continue using Command+Enter shortcut for testing movies in Flash Professional to build and launch since i would certain have a difficult time adjusting to new muscle memory.
thanks.
Grab the Flex 4 SDK, its documentation and the Flex 3 documentation.
Grab the latest actionscript3.tmbundle and install it.
Hit help and read the help, it explains where to put what and how to configure your environment.
For some reason I can't make it work with the Flex 4 documentation but the Flex 3 one works. YMMV.
Even after all of this, TextMate — with all its sexyness — will still be very inferior to Flash Develop: the autocomplete part is very "alpha" and is not "auto" at all, for example.
For the debugging part, I just open the .html with Safari and read the debugging information written to ~/Library/Preferences/Macromedia/Flash\ Player/Logs/flashlog.txt either in the Terminal or in Console.app.
Good luck and feel free to ask for any clarifications.

My under development local drupal site become very slow, how to solve?

I am developing locally a site with drupal and suddenly it became very slow. The last thing I made was installing the internationalization module.
Now when I try to reach administration panel I receive:
Fatal error: Maximum execution time of 60 seconds exceeded...
What to do now? Should I increase the maximum execution time allowed? OR could be that I have too many modules installed?
EDIT: Forgot to tell you that I am working on a PC with 2GB RAM and CPU 2.9 GHz, Windows XP + XAMPP
Exceeding 60 seconds execution time is quite something - indicates that something is going quite wrong.
I'd start troubleshooting by disabling modules (physically moving them out of your modules directory) one at a time until the problem goes away. Then, add them back one at a time, until the problem returns (you'll need to re-enable them through the Modules page as you go). You should be able to quickly isolate exactly which module is causing the problem.
Since the last thing you did was to install internationalization, I'd start by disabling that module.
Once you've isolated the module, you can try to work out what's going wrong.
Some things to look into ...
is your database running out of space
Are you missing any indexes
Do you need to "update statistics" (rebuild metrics on table contents and column distributions)
The Devel module can be useful for logging performance statistics, to help you track down the bottleneck.
A php accelerator may help you get the time down a bit, there are also a number of caching options that your site can use (look in admin under performance), this may make developing more difficult but can make pages load faster.
I wouldn't increase your maximum execution time, at some stage you want to put your site wide, and if people don't get a page within a second or so they will think the site is down.
To have too many modules installed you would have to have a lot of modules, it is more likely that one of your modules is causing a performance bottleneck. Or something on your site like a view is causing things to slow down. mattv's answer helps with that.
try also activating the cache system under site settings / performance. It could be helpful.
there is a known and documented problem about massive queries getting dynamically built by the Views module when rebuilding the dynamic menu, apparently.
Unfortunately, no simple and definitive answer has been found, yet.
You can find more information here (please be aware that some answers relate to version 5).
I would really like to know how to fix this in a definitive and efficient manner.
Use Zend Server. For detailded information check this out: http://drupal.org/node/348202#comment-3349704

ASP.NET Website DLL: Debug vs. Release version

When uploading my ASP.NET web application .dll file to my website's /bin/ directory, are there any disadvantages to using the debug version as opposed to recompiling a release build.
For example, while working locally on the website, the build configuration is set to Debug. When things look good, I go ahead and upload the latest .dll for the website/webapp. Should I instead at that point switch the build configuration to Release, then compile, and then upload that version of the .dll to the server?
I hoping this question isn't a duplicate. I read a number of other questions with similar words in the subject, but didn't find something directly related to my question.
Thanks,
Adam
Running with debug assemblies is a little heavier on performance, as they take up more memory, but usually not extremely so. You should only deploy a release build when it's really a "release". If you still anticipate some level of unexpected behavior in the wild, I'd consider using debug assemblies, so you will get more useful information from unhandled exceptions. The real performance "gotcha" is having debug="true" in your web.config.
A lot of it depends on what your individual needs are. In general people frown on putting the debug build into production for performance reasons. The emitted debug code is apparently not optimized and contains debug symbols that can slow down the execution of the code.
On the other hand, I've worked places where the policy was to put debug builds in production because it makes it easy to see line number, etc, when the code throws exceptions. I'm not saying I agree with this position, but I've seen people do it.
Scott Hanselman has a good post on doing a hybrid version of Debug and Release that could get you the best of both worlds here.
If you have a low volume website, you will never see the performance penalty of a Debug assembly in any measurable way. If you have high volume, look into other means of logging/instrumenting code instead.
On a high-volume website, you DO need to perform extensive stress and load testing to try very hard to break the application before it goes into production. I would do the first pass of that testing with Debug assemblies (since you probably WILL break stuff, and it will make it easier to see where). Then, repeat with the Release assemblies to make sure they behave the same way as the Debug ones.
http://weblogs.asp.net/scottgu/archive/2006/04/11/Don_1920_t-run-production-ASP.NET-Applications-with-debug_3D001D20_true_1D20_-enabled.aspx
Very few applications are going to see a significant difference in performance between release and debug builds. If you're running a small to medium sized application and you think there might be any bugs you haven't caught, use the debug build.

Resources