On mac for instance:
Why do text editors use 30MB RSS just for a text pane, less than 1K chars, open/save, find/replace and a few other basic functions ? They were using way less a few years before, while their functionality did not change.
Why is Firefox using 500~1000MB rss when you browse a few webpages of a few hundreds KB each ? Why does it uses 300~500MB just to startup, even with no addon ?
Why does Safari acts the same, even if it is supposed to be using cocoa libraries which should be shared and in VSZ and not RSS ?
There are many answers to this and I'm procrastinating, so here it goes :)
For better or for worse, the system requirements of software increase because those developing it feel that more hardware resources are available to the typical user of their software. This means:
Less development resources can be spent on fine-tuning (e.g. using higher-level programming frameworks, spending less developer time on optimizing resource usage vs implementing new features and fixing behavior bugs).
New features can be added to the software (I don't know about text editors, but you'd probably be surprised if someone counted the number of new web platform features browsers added support for during the last few years.)
Different memory/performance tradeoffs can be made (i.e. caching more stuff in memory)
Memory usage of simple apps on Mac - see Why do Cocoa apps use so much memory? . Basically, your understanding of Resident set size is quite simplistic.
Browsers' memory usage
Memory usage mainly depends on the content the browsers have to display. You might think you have a "few hundred kb" page loaded, when in fact a typical web page is an application with code for handling or tracking your clicks, a few sub-applications (one for each "like" and "+1" button, or for ads), with another application for the flash applet embedded on the page, etc.
Software is hard, and browsers are very complex in particular (e.g. Firefox has more than 9M lines of code according to ohloh). So an easy optimization can cost a lot more than you might think. A recent example I've seen (681201): when you restart Firefox and it's set to not load the pages in tabs before you switch to a tab, each "empty" tab still uses several hundreds of KB. This is because every "empty" tab actually has a blank HTML document loaded into it and a full-featured JavaScript environment set up, ready to execute code.
Seems easy to fix (just don't create a blank document for empty tabs!), but changing this requires auditing much of the browser code that works with tabs to properly handle the "empty tab" case, and worse, requires changes to add-ons that depend on every tab having a document. So while gradual improvements are being made (down to 160K per tab from more than a megabyte), it's not as easy as it sounds.
Related
I am looking for some advice on how to track application performance; the application is developed using ReactJS, and I am building it with webpack.
First of all I will just present what I have done and what the application is expected to do:
I need to render a lot of, let's just call them widgets, that update real time presenting a lot of data. So, on a scale, I would say each widget renders about 50 to 80 values, these updates might be received from the server side all at once, so they should happen instantly when data is received. Consider I might have around 25 to 30 widgets that need to update real time.
Let me tell you a little bit about the implementation:
I have used the smart/dumb pattern for ReactJS components
The actual data is stored in application state and is distributed by the smart components to dumb components through props
I am using Pure Render Mixin to avoid unnecessary rendering
Also using Immutable data so that I will ensure Pure Render Mixin is working accordingly, that is, being accurate in determining if a render is necessary and at the same time be fast, really fast.
There are no weird bindings of callbacks, that might determine re-rendering of components, this is double checked already.
Now the issues I am having:
with about 5-6 widgets, meaning around 400-500 values that need to render each second, it works very well in Chrome and decent in Firefox.
adding about 25-30 widgets gets the application to still work decent in Chrome, but it starts to act slow in Firefox, by slow I mean user interaction that might even get a delay of around 1 second. That is really unacceptable.
What I have tried:
use Chrome dev tools to measure the performance; that didn't help too much, what I could see though, is that everything is alright. And there is no way I could read all the graphics this tool provides. (And I've read a lot of articles about it)
tried to use Firebug in Firefox. That's an amazing tool, but not in this case; just by opening it with the above mentioned load (30 widgets) gets Firefox to freeze... and the profiler gave me nothing)
on a last resort, I have used the default dev tools from Firefox, it has a performance tab. That got me some information of what parts of the application has the most load on the browser. It seemed it was some heavy computing determining min/max of an Immutable.List.
Unfortunately the application still has performance issues, and it is of high importance to get it working perfect, and Firefox profiler doesn't give me any other leads.
So my questions would be:
what would be the next action to take in order to determine performance issues? (as much as possible where they are: class/method/at least file)
did you guys use any performance testing tool that gives you an insight of what the hell is happening?
is there something else to consider to improve the overall functionality, especially targeting multiple browsers? (Firefox, Chrome, IE11)
Can someone explain me why TWebBrowser control is working so slow on all XE editions of Delphi including XE5 and possibly XE6? To test this you need to create a new Delphi project and put TWebBrowser control in it. On form show event, navigate to this website:
http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html
Please test this on Windows 7 or later. When navigation is complete, run setImmediate test and watch the results. It will take huge amount of time to complete the test. It will take about a minute to finish this.
When you open true Internet Explorer browser and do the same thing - test will be completed instantly (~200 miliseconds).
Some additional wierd informations:
When you recreate this procedure on old versions of Delphi (Delphi 7 to be precise) the web-control works as fast as it should be working and test is completed instantly. But the HTML5 speed test will still works slow (alternative test on this page).
Another weird thing is, the same slow behavior can be seen on C++ Builder but not in Visual Studio products. Is Microsoft deliberately slowing down the TWebBorwser in Embarcadero products?? I can't belive this.
I was trying to overcome this problem with diffrent methods such as:
Trying different feature options in registry such as:
FEATURE_GPU_RENDERING,
FEATURE_BROWSER_EMULATION (11001),
FEATURE_ALIGNED_TIMERS (undocumented option),
FEATURE_ALLOW_HIGHFREQ_TIMER (undocumented option),
Setting timerBeginPeriod(1) - no effect.
Please, if someone have any clue how to fix this issue - share this information with me.
UPDATE1
I made standalone test app if anyone cares. It can be downloaded here: http://mp.org.pl/download/ietest.zip It contains source and exe app with htm file. HTM file contains some js procedure that works 10 times faster in standalone IE than in TWebBrowser control. It uses setImmediate as a test (the same procedure used in test described above). But it can be easier for testing this way.
I can also see the behavior described (in your original post and in the comments). I have a few thoughts, but not necessarily an answer.
One should expect some difference in performance between the WebBrowser control and IE, in part because your Delphi app will need to build in support for certain features/APIs that IE supports out of the box.
For example, the WebBrowser control fires notifications related to tabbed browsing (old, but relevant), but it does not intrinsically handle those notifications or update the UI. You have to respond to the notifications and draw the tabs yourself. By default, IE is hardware accelerated and uses certain Windows APIs that may not be directly supported by Delphi's VCL (for resource/performance) reasons. (Hardware acceleration could account for some of the performance differences you've noticed.)
(And, for the record, I don't believe a list of differences between IE and the WebBrowser control was ever documented. I certainly don't remember seeing one in the portfolio.)
Also, the default values for various feature controls vary between IE and applications hosting the WebBrowser control. Part of the reason for this stems from the idea that IE needs to highlight performance over compatibility whereas applications generally need to emphasize compatibility over performance. You may wish to review the feature control reference to see if there are other FCKs you need to enable for your app.
Second, your loops are very tight, perhaps too tight. You've got one request piling on earlier requests and you're not really leaving much room for processing, even with setImmediate. (IIRC, we're not really supposed to use anything smaller than 250ms for setInterval without risking performance hits from the sheer number of requests.) The remarks in the setImmdiate ref. page provide some guidance, as does this article on requestAnimationFrame.
One reason why dragging the window appears to improve performance may due to the priority of window drag repaint requests. They may be forcing your loops to hold long enough (or even break) to allow other events to process. Hard to say without with tracing the system with a debugger.
Have you ever had to add application.processMessages() to your Delphi apps in order to allow the system a chance to handle the work you've already assigned? A similar need may be coming into play given the nature of your test.
Performance testing and timing is a tricky thing. You need to make sure the test isn't imposing so much overhead that it interferes with the actual work you're trying to perform.
Finally, there were some questions about the document mode of the page as it's loaded into your project. When I first started messing around with your sample, I couldn't get project4 to load slowtest.html in anything other than IE5 quirks mode (notoriously slow). Here's what eventually started working for me:
<!DOCTYPE html>
<!-- saved from url=(0023)http://www.contoso.com/ -->
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
<script type="text/javascript">
...
(Note, I deleted your initial doctype declaration and rewrite it to resolve a syntax error that was being reported by the F12 tools debugger.)
A few style key points here:
I used a mark of the web to load the page in the Internet zone. I find this makes it easier to load the page in edge mode, as pages in the intranet zone are loaded in compatibility view by default (unless you map the zones differently).
The x-ua-compatible header needs to be one of the first in the head block. It can follow title, but not much else.
Stylistically, elements need to be specified in lower case these days. There's a possibility that not following the current conventions forces the parser to fall back to an earlier rendering that supports the conventions.
Once I was able to control the documentMode at runtime, I found results I expected: older document modes ran more slowly. I also found that using requestAnimationFrame instead of setImmediate led to even better performance, but also surfaced the timing issue almost immediately.
In the end, this may be a case where the test highlights a problem, but not necessarily one you're trying to solve. (Insert Inigo meme here.) I get that you're trying to resolve a bottleneck. Are you sure you've found the correct bottleneck?
You may not be able to replicate the same performance of the native browser, but perhaps you can refactor the code to perform adequately without the extra overhead? Is there anything that might be better handled with a worker or some other implementation technique?
Hope this helps...
I am in the process of speeding the perceived load time of a website specifically aimed at the mobile platforms (iPhone primarily, Android secondarily, who cares about the rest...) I have already tried several general techniques for speeding load times for normal websites but I was wondering if anyone had specific pointers for the mobile web performance.
I am already bundling scripts, spriting images, lazy loading as much as possible, putting fixed sizes on things, linking css in the head etc. I want insights specifically for mobile.
For example I have heard that the iPhone will only cache files less than 25k so sometimes splitting a script/file into 25k chunks may give an overall boost since now they can be cached even though it caused additional connections to be made. Any other insights like this would be much appreciated.
Also, does anyone know of a good tool to test the load times in iphone?)
Ok, here's some measuring tools for you...
Steve Souders' mobile bookmarklet - http://stevesouders.com/mobileperf/mobileperfbkm.php (a bit limited on he timing front but has lots of interesting other features)
Stoyan Stefanov's iOS app for exploring page load - http://calendar.perfplanet.com/2011/i-see-http/ (very new, so not sure about it's limitations)
3P Mobile have their own iOS browser in beta that produces waterfalls - Android version was very good.
As far as optimisation goes...
The mobile cache may be small but you still have access to localstorage i.e. include CSS/js inline and extract and save to local storage - Bing mobile does this.
DataURIs are another way of reducing requests but of course the user loses the option to turn off images
Ensure you make good use of keep-alive and connection pipelining - splitting between multiple hostnames can get in the way of these so be careful if you do this.
Caching varies wildly between different phones an OS versions saw an article on it recently will see if I can find it again.
Yahoo! has a nice page about how to squeeze the most performance out of your site.
They also have a Firefox plugin (YSlow) that automatically checks whether your site follows them and suggest improvements. That plugin covers also performance problems that may affect mobile browsers.
I'd like to answer your call for a mobile web site profiling tool - WebDevTools:
https://play.google.com/store/apps/details?id=com.voltcode.webdevtools
disclaimer - I am connected to the company that released this software
While not being targeted for iphones, you could definitely test on various android models and get the load times.
From my experience, IPhone 4+ will load pages the same or better than HTC Desire and similar - both in general speed, but also in HTTP concurrency, etc.
Check out this testing solution:
Tutorial: Does Your Website Load in 3 Seconds?
http://blog.testobject.com/2013/09/does-your-website-load-in-3-seconds.html
I have been following the usage of JavaScript for the past few years, and with the release of extremely fast scripting engines (V8, SquirrelFish Extrene, TraceMonkey, etc.) the possibilities of JavaScript have increased dramatically. However, the usage share of Internet Explorer coupled with it's total lack of support for recent standards makes me want to drop a bomb on Microsoft's HQ, as it creates a huge amount of problems for any website.
The game will need to be pretty dynamic client-side, with animations and other eye-candy things, but not a full-blown game like those that run directly in the OS using DirectX or OpenGL. However, this might be a little stretch for JavaScript and will certainly feel extremely slow in Internet Explorer (given that the current IE engine can be hundreds of times slower than SFX; gotta see what IE9 will bring), would it be better to just do the whole thing in Flash? I know this means requiring the plug-in AND I have no experience whatsoever with Flash (other than browsing YouTube :P). It also means I can't just output directly from PHP, I would have to use XML or some other format to pass data to it (JSON is directly integrated in JS and PHP can deal with it easily).
Another idea would be to provide an alternative interface just for IE, though I don't know how (ActiveX maybe? or with Flash, then why not just provide it to all browsers) or totally not supporting it and requiring the use of other browsers, although this is plain stupid from a business perspective.
So here am I, wondering what approach to take and thus asking for your advice. How should I build the client-side? AJAX in all browsers, Flash in all browsers or a mix (AJAX for "modern" browsers and something else for the "grandpa": IE).
I recommend a plug-in platform (Flash, Silverlight, or Java) over AJAX. Having a clean layer of abstraction between your game and the client's browser is a big advantage. In any non-trivial AJAX game look forward to endless corner-cases where browsers differ in performance or implementation.
Personally, I think Flash is easy to learn if you are coming from AJAX experience. Flash is currently the most widely installed and proven plug-in for browser games. However, Silverlight and Java are both building momentum. Also, the Unity engine has become a popular choice for commercial browser games.
I think you shouldn't leave Java out of the equation. It's a powerful, fast language, and with Java applets, you can do almost anything. If you want hardware-accelerated graphics via OpenGL, JOGL can do it, even in an applet.
On the other hand, it might not be right for you. But at this early stage, I think you should evaluate all of your options, and since you have no experience with Flash but sound like you've got a bit of programming experience, you might feel more at-home with Java.
I believe the current answer is Flash game.
Alternatives:
Java Applet: getting less and less common those days and it is not commonly installed as a plugin on many computers.
SilverLight: too new and might vary and change in time. not commonly installed on many computers and it's Microsoft (whom tends to change technology every 2 years ...)
JavaScript / AJAX: Still a new kid on the block, it's on the rise it is true with many nice features, but still lack of good cross browser for IE even IE8, can not play sounds internally, still slower than the others, and you don't know where will it evolves.
Eventually probably the best solution for now is Flash development:
Cross platform. Works fast. Long time already alive and have a lot of support.
I hope this answer will change in the next year. Happy Peasach.
Check out Jmonkey. The "plugin" loads if you have Java on your machine. Once it's cached, the next time the visitor goes to the page, it your game loads very quick. Check out their website for demos and see what I mean: http://www.jmonkeyengine.com/
Oh, I forgot to say, it's a 3D scenegraph Java engine. I just tried it again, and it loaded in linux. Looks they've put in some good work.
Don't do it with javascript in the browser. And Flash really can be a pain just because it's closed source and you don't know if you've made a mistake or found a bug - speaking from experience. I'd never want to make another Flash game again.
How about using RaphaelJs , it is a Javascript library that make dinamyc images using SVG, and for IE, it try to make those images using the IE alternative: VML. Im using it on my own WebGame, but i dont really make complex graphics in it. The most complex thing done on RapahelJs was a heath map (20 * 20 tiles ) with a dinamyc opacity slider. An it work with jquery without any problem or configuration!
We provide a web application with a frontend completely developed in Adobe Flash. When we chose Flash 6 years ago, we did so for its large number of features for user interaction, like dragging stuff, opening and closing menus, tree navigation elements, popup dialogs etc.
Today it's obvious that AJAX/JS offers roughly the same possibilities and because of the number of frameworks that are readily available, it's very feasible to implement them.
Is there a technical reason one should choose either technology over the other? By "technical", I mean performance, security, portability/compatibility and the like. I don't mean aspects such as the very non-programmer way development is done in Flash or whether it makes sense to switch an app from one to the other.
As I just explained in another question, it seems to me that JS is way ahead in terms of market share and I'm wondering whether we are missing some important point if we stick to Flash.
In addition to what others have said, Flash is constrained in the "rectangle" and cannot be added to a normal html page in an un-obtrusive manner.
#Gulzar I think when more browsers will support the video tag like mozilla 3.1 does we'll see even more adoption of ajax/js over flash.
Adobe Actionscript is a statically typed language, Javascript is dynamically typed. Depending on your point of view, this may be a good thing or a bad thing.
With Javascript/HTML/CSS you're going to be heading into cross-browser compatibility hell, especially if you want to support older browsers. This can be mitigated by the libraries that are available, but it's still a big headache. With Flash, you write the code once and it just works in all browsers.
Even with the libraries available, Flash user controls are simply more advanced than anything you can find in the world of Javascript/HTML. In Javascript, you are not going to find anything that comes close to the simplicity and power of a databound user control that Flash provides.
I don't see how Javascript has more of a "market share" than Flash. Pretty much anyone with a web browser has a Flash plugin installed. I'd be curious to know how many people disable Javascript but have a Flash plugin.
Also keep in mind that you're going to be in for a huge learning curve and lots of development time if you decide to switch your technology base so you'd really better have a good business reason to do it.
This decision also has a lot to do with what your application does and who your install base is.
Edit: I see people have mentioned that the iPhone doesn't have Flash support. I would expect this to change with the install base of the iPhone - Adobe would be crazy not to support it.
Correctly designed AJAX apps are more googleable than Flash
Correctly designed AJAX apps are more easily deep linkable than Flash
AJAX doesn't require a plugin (Flash is pretty ubiquitous, so it's not really a big deal)*
AJAX isn't controlled by a single company the way Flash is
Edited to add:
* Except for the iPhone, as Abdu points out.
JS and Flash both have great presence on the web with overlapping capabilities. One area JS is still lacking is in rendering video.
Flash, used well, allows easy localization and internationalization.
Furthermore, it is much easier to use Flash in an accessible manner; you can feed screen readers the right text, instead of having them iterate over all of the possible form elements.
I think Flash should be limited to online games, videos and animation. Otherwise use html and Ajax. It's a web standard and supported by almost all devices.
AFAIK, the iPhone doesn't support Flash. That's a fast growing segment you're blocking out already. Keep it simple and efficient.
Although flash is pretty ubiquitous on desktop browsers, mobile support is very limited (flash lite? yeah, right). I get really frustrated looking up a restaurant on my phone only to find the entire site is flash based and I can't even get a phone number or address!
One benefit of Flash is that it has a few facilities to help do cross domain type operations safely, which can be helpful. Flash also has (limited) support for some hardware, which is not possible with Javascript.
Personally, I'd try to use as much Ajax as possible before turning to something like Flash. From the UI perspective, it is better in that the controls and basic authoring is a little more developed. The Sound Manager project is a good example of effectively using a small amount of Flash while keeping the remainder in Javascript.
I suspect one of the reasons javascript is becoming more popular is that it's more easy to retrofit into an existing application.
As I can't accept two answers, I'm going to merge Christ Upchurch's and 17 of 26's answers in my own post. I think, these two together pretty much sum up what I wanted to know. Thanks guys!
If you're dealing a lot with polygons, then Flash is still easier to program and debug. With AJAX there are a lot of libraries to handle polygons, but the more libraries your app uses, the slower it gets.