If I have a high-throughput system, should I avoid using Guice to inject objects that are created frequently? Some one has asked how reflection affects performance and it seems pretty bad: Java Reflection Performance.
Guice uses reflection quite heavily.
Reflection on the desktop/server JVM is very efficient, and even very large Guice applications don't have performance problems related to Guice.
Reflection on Android is much less efficient, particularly on older Gingerbread and Froyo devices. Dagger is an open source Guice alternative designed to run efficiently on Android.
Related
I have recently regained some interest in learning Qt, but have the following doubt:
Does Qt have enough classes that are not GUI-related?
For example, Python is "batteries-included", .NET is definitely "batteries-included", and as far as I have seen, Android API also has a lot of classes to design and implement application/domain logic, not directly related to visual presentation.
The main reason I am asking is because I don't know C++ and don't plan to learn it deeply (too much time needed), so if I had to take third party C++ libraries all the time and struggle to use them inside Qt projects that would be a strong point against going ahead.
The intended use is mostly to create small desktop apps for personal use while gaining insight on software design good practices - a profession I am slowly migrating to.
I have already used some Python/Pygtk (without IDE) and WPF (in VStudio/ExpressionBlend). In both platforms, most of my work is related to scientific computations, image processing and interactive scientific visualization, and there are good libraries for that either in Python (Numpy, Scipy, Matplotlib, Pandas, PIL, cairo) and .NET(AForge, alglib, System.Media.Media3D). I wonder if the Qt ecosystem is so complete in that regard.
Qt isn't a language in itself, so you can't compare it to Python or .NET. With that being said, Qt does provide general-purpose classes like containers, a Unicode string class, character set encoders/decoders, multimedia, device and file I/O, etc. All these modules are fully documented.
There are also some external modules available for Qt, like Qwt which provides widgets for technical applications.
For other functionality where something Qt-specific isn't available, you can obviously use another appropriate library. Like OpenCV.
Oh, and you can use Qt in Python too, through PyQt.
As far as I know, Qt doesn't have image processing libraries. For that, you'll need to use something like OpenCV. Qt does have libraries for loading most common image types.
However, Qt does extend beyond just GUI classes.
There is a database module that's quite convenient. The concurrency/threading classes are nice. I've enjoyed making use of the Qt Networking classes. The FileIO classes are alright.
These classes/modules are all useful for making platform-independent code. Things like image processing are mostly algorithmic and tend to be platform-independent by nature. So I think they fall out of the scope of the Qt framework. It shouldn't be too difficult, however, to simply find a library that does what you need and link that in to your project.
A lot of the Qt Core services that heltonbiker and Nikos C. mentioned, can be thought of as extensions to C++, a little like std. Although I often prefer the Qt implementations myself. But Qt has gone much further with their libraries, with the I/O, and web services etc...
The QtXML library provides reading and writing of XML files. Traditionally we had always used xerces, but the Qt XML library is almost as simple as .NETs.
The QtNetwork library offers TCP/IP and other networks services
The QtMultimedia library performs playback and recording of audio
and video content to the use of available devices like cameras and
radios.
The QtSQL library interfaces with SQL databases.
And there is much more than that. Although these are probably services that are used to most. The other benefit is that for the most part the implementations are cross platform. So for example using the I/O services does not require you to write separate code for Linux and Windows. That is a general rule, and there are exceptions. But I am sure most people would agree that any of the services they offer are easy to use, and well documented.
Happy coding.
Qt provides ample abstraction besides UI - it comes with a set of functionality enhancing features that come with certain usage paradigms.
Container classes - shallow copy by value, copy on write
Implicit sharing for containers and certain data types
Event driven, signals and slots
A powerful and usable metasystem
Properties
Platform abstraction for a lot of functionality, from file access to network and multithreading
Cross platform atomics (not that important since C++11 atomics)
Settings API
Undo API
OpenGL abstraction (not necessarily UI, custom graphics)
Basic image formats and basic image manipulations
Qt Declarative, a.k.a QtQuick and QML markup (usable for all kind of structure markup BTW)
Dynamic plugin API
Platform abstraction and portability - same code, multiple platforms
High and low level multimedia - audio, video
Sensors and serial port
Unit test
XML, JSON, SQL
An outdated and hopefully soon updated OpenCL abstraction
Last but not least, a lot of 3rd party modules built around Qt fitting a wide range of applications
Honestly, all its missing is support for some more popular formats for file, media encoding/decoding and containers, some parallel and vector abstraction, USB, WIFI/NFC (in the works in an addon module) and it will be 100% versatile.
Note that you can also use Python with Qt, although I have no experience with that, Qt is a very versatile tool that allows for quick and easy application development - and since 5.1 supports pretty much the entire market, with the addition of Android and iOS to the list of supported platforms. It is very useful for creating custom use applications for creative or research purposes.
Although not perfect for every task, Qt is easily the "best of the bunch" of tools you can use in this regard. Unbeatable in terms of portability and very thorough, if not a little bloated for the set of functionality it provides. And finally, it is free, you can even develop commercial applications under LGPL as long as you link dynamically. All in all, it is well worth the investment to learn, the only downside is it lacks uniformity between the old C++ native APIs and the QML runtime, which is actively worked on and is based on JS, so the APIs are a bit different and some glue APIs are required to fuse C++ with JS and QML.
(just for the record, from the official site):
The Foundation: Qt Core Module
The Qt Core module forms the foundation of all Qt-based applications
with core non-graphical classes used by other modules.
Key Functions
File IO, event and object handling
Multi-threading and concurrency
Plugins, setting management
Signals and Slots inter-object communications mechanism
Benefits
Reduce development time and cost by leveraging a complete set of application building blocks
Develop portable code from the ground up with cross-platform functionality
My company is building a Flex application that we may need to port to other platforms:
Silverlight (likely)
Mobile (maybe -- iPhone: Objective-C , Android: Java, etc.)
Desktop (maybe -- AIR, .NET, etc.)
TV sets (maybe eventually)
Currently, I’m looking into application frameworks to build upon and I’m torn between pureMVC and Swiz.
I LOVE swiz for its simplicity and how it just gives you a way to hook things up and then apply your own patterns. From a flex-only perspective, this is my 1st choice.
But, PureMVC is platform-independent and has already been ported over to most of the platforms that are mentioned above. How valuable is this portability? Will it really make our lives significantly easier when it comes to porting and developing/maintaining multiple applications? If so, then it seems like PureMVC is the way to go.
Alternatively, since Silverlight has the most definite business case for porting of our application, maybe we could port Swiz to Silverlight? I'm not too familiar with which AS3 language and Flex framework features Swiz depends on and whether they are available in C#/Silvelright. Would this actually be possible?
Thanks so much!
Karthik
The way I see it, if you used pureMVC you could port to a new language, without too much trouble (other than what the new language will give you) your commands, mediators and proxies, provided you program your mediators to an interface, instead of a concrete component implementation, and the proxies use a services layer to get the data from server. That way you'll only have to implement the components and the service layer in the new language.
A quick look at the Swiz framework:
uses the flash event model (see CentralDispatcher)
uses some flash.net, and mx.rpc classes (see net and rpc swiz packages)
PureMVC framework doesn't use the flash event model, and eventual flash.net/mx.rpc references would normally appear in the service layer. On the other hand Swiz seems to be aimed at taking full advantage of flex, and the mxml format, so it might get the job done faster there. So you might also want to consider using Swiz for flex and PureMVC for the other languages.
Any framework, including Swiz, can very easily be ported to just about any language. Actionscript is touring complete, so theoretically any code writen in actionscript can be transformed into another touring complete language. For example, we use the Swiz framework in our mobile apps, which get cross compiled to run in iOS. There are many other open source cross compilers for a variety of languages, as well as Adobe's Alchemy project.
The only thing that is not easily portable in Swiz the usage of runtime metadata tags. This can be solved by using an advanced search and replace utility, or a custom transformation framework to convert custom metadata tags to their native code implementation. Hopefully we will see some cool new open source tools for this soon, now that Flex 4.5 was released with custom compiler hooks.
In short, I wouldn't even take portability into consideration when deciding on a framework. Choose the one which is most comfortable for you or your developers to use. I personally prefer Swiz myself.
Cheers!
I have seen a few blog entries on this and have had a discussion or two with my team mates but I would like to see what the stack overflow community thinks.
So why does the Adobe Alchemy Tool create so much faster running flash byte code than the flex compiler?
Also, when will the flex compiler be able to make similar performance gains?
Will it require programmer specific use of special Array's or something of that nature to get the same performance?
Alchemy is an implementation of LLVM in ActionScript. Simply put, it's an virtual machine that uses a ByteArray as it's memory store.
The C code compiled by Alchemy has direct access to "memory" (via some opcodes introduced in Flash 10), allowing it to chunk memory around at it's leisure (including pointers to objects). This results in some, but by no means all, code running faster. Some types of code will actually run slower in Alchemy due to it being a VM running on top of the AVM (another VM).
Additionally, Alchemy does not have native access to ActionScript classes and must access them through interop classes.
The alchemy tool creates code that uses instructions in the flash player that aren't available to the regular compiler (and the talk is that these instructions were exposed especially for alchemy).
Whether the regular compiler will eventually make similar gains, hopefully. It's been proven a few times that the compiler creates substandard code, and there are a couple of projects which optimise the generated code. These may shame Adobe into improving.
Chances are, no, there won't be anything special a programmer needs to do to get these performance gains (though check out the optimising blogs, writing loops in a particular way means they can be optimised better).
I'm looking for a fast language (ie. a language that can be compiled natively to achieve performance not more than 3 or 4 times slower than C), which supports portable continuations. By this I mean a continuation that can be serialized on one computer, and deserialized on another.
I know that SISC can do this (a Scheme implementation in Java), but its slow. Ditto for Rhino (a Javascript implementation in Java).
Did you checked OCaml ? It can be compiled and should be marginally slower than C.
Continuations and delimited control
Scala 2.8.0 will allow continuations, and they'll be portable.
While I agree that dialects of Caml might be an excellent choice I feel I have to mention Gambit Scheme. Together with Termite, an erlang-like framework it has support for serializing continuations, sending them over the wire, and much more.
It compiles to C-code.
Its possible to do serializable continuations in Java using Apache JavaFlow - if you do go that route then the Swing Continuations library at:
http://www.exploringexcellence.com/swingcontinuations/download.html
makes it the coding a lot more pleasant.
One of the stated goals of the PureMVC framework is to avoid platform dependencies in order to be portable. Considering that because of language and API differences application code will always be heavily dependent on the platform, and that avoiding platform dependencies makes the framework reinvent the wheel and/or only provide a least-common-denominator feature set, in what way does the portability of the framework benefit me as an application developer?
I've worked with PureMVC. They're trying to implement their stuff in quite a lot of languages. You may be right about the least common denominator, but overall, it's not a bad framework, and I've seen a really nice AS3 app in PureMVC.
I don't think they're talking about portability in terms of porting actual code. The idea there is more that you're using a generalized MVC architecture, which you could apply to other projects and other languages.
They're trying to say that if you become familiar with the PureMVC pattern, you could potentially come into a new PureMVC codebase, even if it's another language, and you would already know the lay of the land.
You might also say that developers who develop good PureMVC skills are likely to develop good habits which will translate as they go from language to language. But then again, maybe not.. for the reasons you mentioned.
We've been using PureMVC on two projects now and in my opinion the attempted language-independence is quite a burden.
The promise of jumping straight in a project because the framework is already know does not seem relevant to me if the languages are not already pretty similar (C# to java would make sense, as3 to php not) -- I agree that it is useful to have known ways of solving things, but for that the 'plain' patterns are good enough.
However, I also don't really agree with the usage of the various patterns the project uses, so our choice to not use it on the next project might be related to both issues, and not just the attempt at language/platform independence.
PureMVC's portability will help you when you migrate to or reimplement in another language.
I can't count the number of platforms and languages I've written code for that are now extinct and for which, even if I still had the source code it would be mostly worthless and have to be rewritten from the ground up today, since the code was usually 100% platform specific.
But all application code need not be heavily dependent upon the platform. View components and services (the boundaries of your application) will necessarily be, but your application logic which is sandwiched between the boundaries need not be.
The scope of PureMVC is really quite narrow; merely to help you split your code into the three tiers proscribed by the MVC meta-pattern. There is no reason why this code has to be tied deeply to your platform in order to be optimal.
When it comes time to migrate, you'll appreciate that the framework actors and their roles, responsibilities and collaborations remain the same. This leaves you to deal with syntactic differences of the language, recreating the view components and services. At least you won't have to completely re-architect.
And for the case of reimplementing in a different language, imagine you're trying to capture a significant part of the mobile market with your app. The market is so fractured, you'll have to implement the same program on 2 or more of Windows Mobile, iPhone, Flash, and Java. Sure you'll probably have separate teams in charge of the apps, but why have a totally different architecture? With PureMVC, you could have a single architecture for all versions of your application.
-=Cliff>
PureMVC is the only real option for Flash Platform developers who choose not to use the Flex Framework. For certain projects the size cost of Flex is too expensive (it happens!).
I like to prototype in Flex and then rip it out and replace my views with custom components when the application is near completion. PureMVC makes this really easy to do with it's Mediator pattern. I'm not sure there is any other framework that would allow me this workflow.
Personally, I think PureMVC went too far with it's portability goals: I enjoy that fact that it works with Flash AND Flex (for the reasons mentioned above), but feel that it should have stopped there, and made use of the native Flash Player event architecture.
Are there examples of people using PureMVC to build and port applications across multiple platforms?
My company is building a Flex application that we may need to port to other platforms:
Silverlight (likely)
Mobile (maybe)
Desktop (maybe -- not just AIR!)
TV sets (maybe eventually)
I am considering PureMVC as a framework if it can ease porting and maintenance. I am curious to know if other people have ported a PureMVC app to a different platform and what their experience was with porting and then having development proceed in parallel for the app on multiple platforms.
Cheers,
Karthik
PureMVC does not rely on a platform for its internal workings (Flash Events etc).
So, while it does not make porting any easier per-say, it can assist simply by showing us its friendly and familiar face wherever we may choose to go ;-)