I'm working on a javascript profiler for Mozilla Firefox, that would let me obtain all available information about the execution of the script on the page (DOM object calls, events, calls to functions like Math.random(), document and navigator object calls, as well as code's own execution tree with arguments etc etc).
Currently, I think that the best way to implement this sort of profiler is by modifying Firefoxe's own source code.
One way to go about it is to find all implementations for corresponding method calls and add profiler log calls there. But there are 2 problems with this approach:
The methods and objects are widely scattered, and I'm not really familiar with the source code at this moment. Tracking down all the functions and making sure that the profiler works as intended will take A LOT of time
When created in this way, the profiler is going to be difficult to maintain when Firefox source code evolves with time.
So I was wondering, if there is a single class/a small group of key classes in firefox source, that could be modified to allow me to collect the information I want? Or is there a better way of doing what I need to do?
The latest Aurora release of Firefox has a basic profiler built into its developer tools, or you can download a more advanced interface from the Mozilla Add-ons site which works with Firefox 16 or later.
Related
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...
Is there a tool to measure the performance of my firefox extension. And is there a toll which part of my script takes lot of CPU?
You seem to be looking for a JavaScript profiler. Unfortunately, I don't know any good profilers for this. The usual recommendation would be Firebug but it doesn't work for add-ons (maybe with Chromebug but I'm not sure about that). There is also XUL profiler which is outdated but might still work in newer Firefox versions (you can use Add-on Compatibility Reporter to install and test incompatible add-ons). And there is JavaScript Deobfuscator which is meant for something different but can do some basic profiling as well. There you can adjust the filters to include only JavaScript files of your extension and see all the functions that are being called - along with the number of calls and the average execution time. This is sometimes good enough to identify the bottlenecks.
Does anyone know of any tools out there that will let me run and debug a VXML application visually? There are a ton of VXML development tools, but they all require you to build your application within them.
I have an existing application that uses JSPs to generate VXML, and I'm looking for a way to navigate through and debug the rendered VXML in much the same way that Firebug allows one to do this with HTML. I have some proxy-like tools that let me inspect the rendered code as it is sent to the VXML browser, but there's a ton of JS, which makes traversing the code by hand rather difficult.
Has anyone worked with a product that allows for this?
Thanks!
IVR Avenger
There is JigSaw Test suite - has free trial license and reasonably priced.
There is IBM's debugger - part of WebSphere Voice Toolkit.
Many other products have debuggers - a very good summary is here
Disclaimer: I am the development manager for Voiyager (www.voiyager.com), a VoiceXML testing tool. It doesn't meet your criteria nor do I believe it is the type of tool you want, but I thought it was worth mentioning it.
As far as I know, there isn't such a test tool for VoiceXML. In fact there are very few VoiceXML tools on the market and hardly any of them test or analysis. The vendors that created development tools, have all been acquired by other companies. Some of them offered did offer various forms of debugging that were specific to their tool set or stayed at the Dialog (caller input) level. From your question, I'm assuming you need much lower level debugging capabilities.
I think the alternative paths are minimal and somewhat difficult. I believe your primary goal is to debug or rewrite an existing application, but you haven't provided any specific challenges beyond the JavaScript. Some thoughts or approaches that may help:
Isolate the JavaScript and place the code into a unit test harness. That will go a long way to understanding the logic of the application. Any encapsulation of the JavaScript you perform will probably go a long way towards better code maintainability.
Attempt to run the VoiceXML through a translation layer to HTML so you could use FireBug. The largest challenge would involve caller input (ie processing the SRGS grammars). You could probably cheat this by just having the form accept a JSON string the populates the field values. There are tools on the market to test grammars. Depending on the nature of your problems, you could take a simple and light approach and attempt this over just the trouble areas.
Plumb the application with a lot of logging. This can be done through the VoiceXML LOG element, or push the variable space back to the server. By adding intermediate forms, you may be able to provide a dump from each via the VoiceXML Data element.
See if your application will run in one of the open source VoiceXML browsers (not sure of the state of the open source browsers as we've built and bought for our various product lines). If you can get it mostly working, you can use the development debugger to provide some ability to step through the logic. However, it is probably one of the more difficult paths as you'll really need to understand the browser to know when and where to stick your breakpoints and to figure out how to expose the data you want.
Good luck on the challenge. If you find another approach, I would be interested in seeing it posted.
An alternative debug env is to use something like Asterisk with a voicexml browser plugin like the one from http://www.voiceglue.org/ or for a limited licence, i6net.
You can keep all the pieces separate(dynamic html and vxml application in php/jsp/j2ee/, tts processing, and optional asr processing as separate virtual machines with something like virtualbox. If the logic can be kept the same, then it is just a matter of changing the UI based on the channel.
A softphone is all you need to call a minimal asterisk machine, which has the voicexml browser with the url of the vxml in the call plan.
I just used Zend Framework as php is used in this environment, and changed view suffixes(phtml vs vxml) based on the user-agent string.
Flite for tts is fine for debugging, and when your app is ready you can either record phrases, and there was a page on the ubuntu forums with directions for how to increase flite quality with some additional sound files.
Do you have tried Eclipse VTP or InVision Studio?
Eclipse VTP
This is Eclipse plugin. But I feel that it is user-unfriendly a little (of Japanese viewpoint).
InVision Studio *Required create user account*
This is Convergys's IVR tool. It has to edit standard VXML mode. (Unfortunately, It's not exact matching.)
For just debugging vxml, I use Nuance Cafe's VoiceXML checker. It doesn't give you a visual tree or anything, but it's pretty good at spotting syntax errors and is free. I think they might also have more advanced debugging tools if you look into it, but I haven't had the need. (Note: I have no association with them)
http://cafe.bevocal.com/tools/vxmlchecker/vxmlchecker.jsp
I'm looking for the same problem that most of the links are down. I found a document where they propose an open source solution, which works as a plugin for Asterisk (https://www.researchgate.net/publication/228873959_Open_Source_VoiceXML_Interpreter_over_Asterisk_for_Use_in_IVR_Applications) and is available at https://sourceforge.net/projects/voxy/
I would like to know if there are current options to create a VXML structure graphically, like the next image.
I want some personally developed JavaScript code to execute whenever I load a page in Safari. Seems like addblock for Safari does this. Anyone know how to do this?
Safari is not extensible. There's no addon framework for it. But yet there's adblock and verious other addons available for it, although Apple's Webkit and Safari developers discourage users from using them, calling them 'binary hacks'. Seems though some of these addons use InputManager, which isn't documented at all anywhere, at least for not for how people are using it to load scripts in Safari. I guess I'm going to have to backwards engineer to see how addblock does it, but before I do, I thought I'd ask around here. Anyone know?
Input managers are a commonly (ab)used way of injecting arbitrary code into another application's runtime. Once you are there, you have to reverse-engineer enough of the application itself to figure out how to get the behavior you want; usually that involves method swizzling to replace parts of the application you are hacking. It's not documented because there's no API to document, but you can learn about the individual pieces (how to write an input manager in general, how method swizzling in Objective C works, how to use tools like class-dump) and then put it all together.
What you are describing sounds like Greasemonkey though, and there are least one or two hacks already out there to enable Greasemonkey-like behavior in Safari. I'd suggest seeing if one of them meets your needs first.
I'd like to learn how FireFox works behind the scenes. I'd like to understand the source code and the different components but the code-base is rather large and I'm not sure where to start.
I'm wondering if there is some sort of walk though written up by anybody either from the firefox team or from outside the community.
I've looked a little bit at: https://developer.mozilla.org/En but I don't see anything that screams "Start here". I'm simply trying to review their code base for [self-]educational reasons.
Seneca College in Toronto has a program geared towards exactly this -- beginners to Mozilla development.
Check out some of these links:
Real World Mozilla
Fall 2008 Weekly Schedule
Some labs if you want to dive right in:
Lab: Learning Collaborative Development (Fall 2008)
Lab: Building Open Source Projects (Fall 2008)
Lab: Real World Mozilla - Source Code Reading
Lab: Working with Patches
Lab: Dive into Mozilla - Debugging Mozilla
Lab: Thunderbird Bug Fix
Lab: Modifying the Browser
Lab: Modifying Firefox using an extension
Lab: Real World Mozilla - First XPCOM Component
Lab: Real World Mozilla - Adding chrome to first XPCOM component
If you need any help, use IRC: #seneca on irc.mozilla.org. Don't worry if you're not a (Seneca) student, lots of people around the world (people from Seneca, people from Mozilla, and others) are in this channel, the purpose is to educate developers about open source in general and the Mozilla project specifically.
Good luck!
Here's a top-down answer (most of the others are bottom-up):
Firefox is a XUL application (see also: XUL); XUL is a variant of XML used to describe a GUI that is interpreted by a renderer, much the same way that HTML is rendered within the browser, but XUL includes the browser's menus, buttons, status bar, keyboard shortcuts, etc. It's pretty neat; I've been able to put together some simple GUI apps much faster in XUL than in other frameworks (and it's platform-independent!).
If you look in the Firefox application directory (wherever you installed it on your system), you'll see a "chrome" directory with a bunch of .jar files. These are just .zip files with a particular structure (including a manifest) and you can look through them yourself.
Much of the Firefox browser is actually XUL + Javascript. It does utilize a lot of lower-level libraries written in C++ and accessible to Javascript via XPCOM, but if you want to understand (& modify) the higher-level behavior, the XUL+Javascript parts are probably the place to start.
edit: p.s. here are some tutorials/references for XUL: 1 2 and also the O'Reilly book
edit: XUL documents are very similar to HTML documents (only more so!) in the way they interact with the user + events. There's a document model for dynamically modifying the XUL, and there are event models that have event listeners. Both act just like HTML + DOM + its event model, but with a richer set of builtin objects/interfaces/events/etc. The event handlers are interfaces of a particular sort, and can be implemented by Javascript objects (declared in the XUL with onclick="blah()", or added dynamically through Javascript calls to addEventListener() -- both are exactly the same syntax as HTML events in Firefox) or by C++ or other languages that can implement XPCOM objects with the proper interfaces.
One way to start would be to look at some recently fixed bugs in Firefox (see Bugzilla) and take a look at how they were fixed.
That said. The Firefox codebase is very large, and it's likely that no one person understands all of it, so it would be a good idea to start off with a small section (say favorites), and try finding the code for it and looking at how it works. Again, resolved bugs and the files they affect would be a good way of identifying some relevant code to start with.
i worked with mozilla code ( precisely mozilla/nss/security). as far as my understanding of mozilla goes :
It follows layered architecture with NSPR layer (Netscape Portable Runtime ) at the bottom which interacts with Operating Systems.
get the source code from
https://developer.mozilla.org/En/Download_Mozilla_Source_Code and build it in your working environment( as far as i know it support wide variety of platforms/architectures)
join Mozilla developers community/ try to help through testing some of the components.
to code for mozilla, go through :
http://www.mozilla.org/hacking/ ( C++ portability standards is a must if you are C++ programmer).
hope some of the above might help you getting started.
A set of videos was recently released (as for beginning of 2015) that walk through the some of Mozilla Firefox components. Maybe you would be interested in them.
https://air.mozilla.org/search/?q=tag%3A+TorontoBootcamp
They aren't very newbie but still can be helpful I think.