I am trying to decide what application paradigm to use for my iOS app build with Appcelerator. Many people talk about the Tweetanium way as the best way, i.e. single context.
I think I am going to use that but I have a few questions about it.
Since I include all "windows" on the first page. Does that mean that it will have to load all windows in the application at app start?
Will this paradigm really be very fast and memory conservative compared to "normal" way of for example the Kitchensink?
What is the downside of using Tweetaniums way of doing things?
Is it suitable for complex apps?
Thankful for all input!
Short version: Yes :)
Longer version:
Multi-context apps (like the Kitchen Sink) are also fine generally speaking, but you run into the following two problems with larger apps:
1.) Sharing data between windows/contexts within an app
2.) Unsure when the code for a given window has been run
You can also (potentially) maintain a pointer to a UI object created in one context after the window associated with that context is closed, which under some circumstances can lead your app to leak memory. Single context is easier and will ultimately get you into less trouble. Also, if your app is large, be sure to only load scripts as you need them, and not all up front.
Related
I understand why cold starts happen (Byte code needs to be turned into machine code through JIT compilation). However with all the generated meta data available for binaries these days I do not understand why there isn't a simple tool that automatically takes the byte code and turns ALL PATHS THROUGH THE CODE (auto discovered) into machine code specific for that target platform. That would mean the first request through any path (assume a rest api) would be fast and not require any further Just In Time Compilation.
We can create an automation test suite or load test to JIT all the paths before allowing the machine into the load balancer rotation (good best practice anyway). We can also flip the "always on" setting in cloud hosting providers to keep the warmed application from getting evicted from memory (requiring the entire process over again). However, it seems like such an archaic process to still be having in 2020.
Why isn't there a tool that does this? What is the limitation that prevents us from using meta data, debug symbols and/or other means to understand how to generate machine code that is already warm and ready for users from the start?
So I have been asking some sharp minds around my professional network and no one seems to be able to point out exactly what limitation makes this so hard to do. However, I did get a few tools on my radar that do what i'm looking for to some level.
Crossgen appears to be the most promising but it's far from widely used among the many peers I've spoken to. Will have to take a closer look.
Also several do some sort of startup task that runs some class initialization and also register them as singletons. I wouldn't consider those much different then just running integration or load tests on the application.
Most programming languages have some form of native image compiler tool. It's up to you to use them if that is what you are looking to do.
Providers are supposed to give you a platform for your application and there is a certain amount of isolation and privacy you should expect from your provider. They should not go digging into your application to figure out all its "paths". That would be very invasive.
Plus "warming up" all paths would be an overly resource intensive process for a provider to be obligated to perform for every application they host.
My application has several large forms with lots of images which dramatically increases the size of the built executable. Over time, it seems that the startup performance becomes sluggish and it doesn't seem to be getting any better.
If I put all of the forms besides the main form in a separate dll, would it alleviate some of the pressure put on the application during startup?
I'd test it myself, but I have A LOT of forms and I don't want to do it unless someone can confirm that such an action will prove to be useful.
Many factors can affect startup performance. Have you used any tools to prove that it's the images?
For a start, go through these tips:
http://devcomponents.com/blog/?p=361
And consider using multithreading to load bigger objects in the background.
I'm not quite sure about that, but if I were you I would use the Profiler when it comes to improving performance.
Before I go guessing what's wrong, I consult with it and work my way up, because it tells me which methods and classes are costing the most in my code.
Another tip that may be useful: This reduced my application's startup time from 2 minutes to <10 seconds on a low-end thin client. Use NGEN to generate a precompiled native image of your assemblies.
I'm wondering if you were to use MEF and Lazy load, then when you actually need the module (Form) instantiate by calling .Value.
There are a couple of things I do with applications containing a lot of forms:
Create a UI .exe: basically only my forms
Create a backend .dll: everything that does the work behind the UI.
Are the images actually included in the .dll? If so, I would actually put my images into a .dll separate from the UI.
Given that the images are for toolbars, I wouldn't split them out as resources. I'll still stand fast on my advice to split into multiple .dlls.
As others said, profile, don't guess.
Not just any profiler will do.
Here's a user (besides me) who discovered random pausing on his own.
You say the "intense" methods are all in dlls you don't have source code for - that's typical and normal.
What you need to know is which statements in your code are requesting the time to be spent, and they can't be restricted to CPU-only time.
Most profilers don't tell you this, but random-pausing does.
If you're interested, here's a recent discussion of the issues.
I have a simple problem, I will be straighforward.
Suppose I have a third-party cocoa application running that has a chat box inside. Well, I need to capture the text inside that chat-box in real time from another application and write a logfile in real time with that information.
I am sure there is a way, I just don't know where to start. I have experience with cocoa and objective C, I have some apps in the iphone app store.
Thank you very much
Unless the app is suitably scriptable (e.g. AppleScript) or has some kind of external API then you're not going to be able to do this.
In short: Contact the developer of the application, but don't get your hopes up.
Unfortunately, in this day and age of protected memory and whatnot, we more or less have to be content with what the applications give us to work with.
However: You are not entirely without recourse. Using F-Script you might be able to attach to the process and cause some controller or other to emit notifications that you can capture and log.
Edit: If, as appears to be the case, it's a Carbon application, you are well and truly hosed:
F-script and similar is unlikely to be possible.
Even if it is, trying injection on a Carbon app, that is to say, a C++ app, is likely to be an exercise in futility and disappointment, if not completely impossible.
Seeing as how Carbon is deprecated (and how!), the application is unlikely to be updated with a proper API for that sort of thing.
All of the above.
Reedit: One tiny little aber; it is possible, although unlikely, that you can achieve something using Interface Scripting, but again; I wouldn't get my hopes up.
What do you do to increase startup speed (or to decrease startup time) of your Delphi app?
Other than application specific, is there a standard trick that always works?
Note: I'm not talking about fast algorithms or the likes. Only the performance increase at startup, in terms of speed.
In the project options, don't auto-create all of your forms up front. Create and free them as needed.
Try doing as little as possible in your main form's OnCreate event. Rather move some initialization to a different method and do it once the form is shown to the user. An indicator that the app is busy with a busy mouse cursor goes a long way.
Experiments done shows that if you take the exact same application and simply add a startup notification to it, users actually perceive that app as starting up faster!
Other than that you can do the usual things like exclude debug information and enable optimization in the compiler.
On top of that, don't auto create all your forms. Create them dynamically as you need them.
Well, as Argalatyr suggested I change my comment to a separate answer:
As an extension to the "don't auto create forms" answer (which will be quite effective by itself) I suggest to delay opening connections to databases, internet, COM servers and any peripheral device until you need it first.
Three things happen before your form is shown:
All 'initialization' blocks in all units are executed in "first seen" order.
All auto-created forms are created (loaded from DFM files and their OnCreate handler is called)
You main form is displayed (OnShow and OnActivate are called).
As other have pointed out, you should auto-create only small number of forms (especially if they are complicated forms with lots of component) and should not put lengthy processing in OnCreate events of those forms. If, by chance, your main form is very complicated, you should redesign it. One possibility is to split main form into multiple frames which are loaded on demand.
It's also possible that one of the initialization blocks is taking some time to execute. To verify, put a breakpoint on the first line of your program (main 'begin..end' block in the .dpr file) and start the program. All initialization block will be executed and then the breakpoint will stop the execution.
In a similar way you can step (F8) over the main program - you'll see how long it takes for each auto-created form to be created.
Display a splash screen, so people won't notice the long startup times :).
Fastest code - it's the code, that never runs. Quite obvious, really ;)
Deployment of the application can (and usually does!) happen in ways the developer may not have considered. In my experience this generates more performance issues than anyone would want.
A common bottleneck is file access - a configuration file, ini file that is required to launch the application can perform well on a developer machine, but perform abysmally in different deployment situations. Similarly, application logging can impede performance - whether for file access reasons or log file growth.
What I see so often are rich-client applications deployed in a Citrix environment, or on a shared network drive, where the infrastructure team decides that user temporary files or personal files be stored in a location that the application finds issues with, and this leads to performance or stability issues.
Another issue I often see affecting application performance is the method used to import and export data to files. Commonly in Delphi business applications I see export functions that work off DataSets - iterating and writing to file. Consider the method used to write to file, consider memory available, consider that the 'folder' being written to/read from may be local to the machine, or it may be on a remote server.
A developer may argue that these are installation issues, outside the scope of their concern. I usually see many cycles of developer analysis on this sort of issue before it is identified as an 'infrastructure issue'.
First thing to do is to clear auto
created forms list (look for Project
Options). Create forms on the fly
when needed, especially if the
application uses database connection
(datamodule) or forms that include
heavy use of controls.
Consider using form inheritance also
to decrease exe size (resource usage is mimized)
Decrease number of forms and merge similar or related functionality into single form
Put long running tasks (open database connections, connect to app server, etc) that have to be performed on startup in a thread. Any functionality that depends on these tasks are disabled until the thread is done.
It's a bit of a cheat, though. The main form comes up right away, but you're only giving the appearance of faster startup time.
Compress your executable and any dlls using something like ASPack or UPX. Decompression time is more than made up for by faster load time.
UPX was used as an example of how to load FireFox faster.
Note that there are downsides to exe compression.
This is just for the IDE, but Chris Hesick made a blog posting about increasing startup performance under the debugger.
I'm having trouble deciding if I want a project of mine to be web-based (as in a web-app), desktop-based (a desktop application), or a desktop application that can sync or connect to the cloud.
I don't know if anyone else would have an interest in this application, and it's only going to be for me, so I'm leaning toward desktop application. If, for some reason, I finish it, release it, and people actually like it, I might see about making it sync to the cloud as well (think v2). But I'm not sure how hard it is to make such a radical change, and I don't want to end up with something good that is useless because I made a poor choice before I even started the project.
Is there any sort of guidance for this? Any rules of thumb or best practices? Any personal experiences?
If the language matters, I'm thinking about Java simply because I'm most comfortable with it, and it would easily allow me to share it with my friends for testing and if I get stuck and need help from someone else in person.
I generally ask a few questions:
Can it even be done on the web? Something I did not too long ago involved an image editing component, and had to be a web app. It involved much pain to get this work, and a desktop app would have been a far better way to go.
Will I need to access it from anywhere? Yeah you could load it up on a thumb drive, but the web is far more feasible in this case.
Will there be multiple users? This could go either way, but "long tail" stuff usually means web.
What tech do you want to use? The latest and greatest WPF based UI? Desktop (yeah yeah, silverlight, let's not go there ok?). The brain dead stupid easy user management of Django or others? Web.
If it were a web app, will you need to worry about common attack vectors like SQL Injection, XSS, etc? A desktop app has its own issues here too, but tend to have less exposure.
How resource intensive is it? Will 10 users kill performance of a web server?
Versioning on the desktop can be a pain, whereas with a webapp everyone is on the same version. This can bite you though, see the New Facebook user pushback.
EDIT:
Cost can be a factor too. A web app with a database backend typically means a web server. If you want to stick with, say, the Microsoft Stack, you'll need licenses for SQL Server which can get pricey. Open source is cheaper, but may not be an option in all cases. "Serving" a desktop app is generally cheaper.
If you release as a web-app, you won't have to port it over. You'll also have access to it wherever you go.
I base my choice on the GUI mostly. If the GUI is going to be complex, and (needs to be fast or will have aspects of it that will take a lot of time to process) then I will go with the Desktop. If it is simple, and will always have small data sets to work with at once, the I will go with the Web.
I have worked on an app that was made as a web app, when clearly it was better suited for the desktop. It was a massive failure. I don't know HOW customers put up with it, cause I certainly wouldn't have used it. The desktop version (which took over 6 months to re-write) blew the web version out of the water.
That being said, I have seen some nice web apps.
All I can suggest are several factors that would be relevant. How you determine the answer and weight for the factor is up to you and other circumstances:
What is your audience? Do you have any control over them?
How complex are the interactions you expect to implement?
Do you require near real-time data updates?
How often do you expect to update the application after the first release?
Do you expect a well-defined set of client platforms, or can you not predict that?
Note that your choices also can include a Java WebStart application, which mitigates some of the disadvantages of a typical desktop application.
I'd say that most applications should be desktop-based. The advantages are faster and more fluid apps.
You should only create a web application if there are obvious benefits from it, like access from everywhere. (If that's necessary for your app.)
A downside of web applications can also be that it is dependent on the developer, if you quit supporting it all your users (if you'll have any) can't use it anymore. Furthermore, there is a chance that users are not willing to store their data online.
Ultimately it depends on what kind of an application you want to write. Even if you create it as a desktop-app, you can later on rewrite it for the web. Often a 2.0 version of software needs almost complete rewriting anyway.
Sometime web can be good and sometime not. We are in a new wave that go in the web but do not forget few things:
GUI in web is more complicated because of multiple browser
People who need to work on your system might not like working the whole day in a browser
Web can be slower for some application (image editing, hard job that require a lot of CPU)
Rapid Gui like Visual Studio for winform are faster than for web
But web has many advantage in the deployement and in the portability. If your system is well structured you could make both or change to one to other later with something build with MVC. Just change your visual and you will be fine.
If this were an application to be used my multiple users, with shared data, you're probably going to want a server anyway. In that case I'd lean towards a web application.
Otherwise you've got the complexity of syncing data between the desktop and a server.
Two important questions not on the list so far:
Will the first version have any features that need lowish-level access to hardware?
Will future versions have any featuers that need lowish-level access to hardware?
It's pretty easy to answer the first one, but giving the second one some thought can save you some headache down the road.
My default choice is to go with a web solution, as it's easier to deploy and generally multi-platform. The only time I go with winforms apps is when there are pressing security, performance, or functionality issues that require it.
Previously you'd have written a desktop application, as tool were better for that and you'd have written it faster. People used to want web apps, but always ended up with desktop.
Nowadays things are different, you can write a webservice just as quickly and easily so there's no reason not to go web-based.
The advantages of web-based are flexibility, scalability and ease of deployment. It won't be as responsive as a desktop app could be, but that's not so much of an issue if you think about your design.