My first question =). I'm writing a video game with a user interface written in JavaFx. The behavior is correct, but I'm having performance problems. I'm trying to figure out how to figure out what is queuing up the refreshes which are slowing down the app.
I've got a relatively complex Scene Graph that represents a hexagonal map. It scales so that you could have 100 or a 1000 hexagons in the map. As the number of hexagons grow the responsiveness of the gui decreases. I've used YourKit (a Java Profiler) to trace these delays to major redraw operations.
I've spent most of the night trying to figure out how to do two things and understand one thing:
1) Cause a CustomNode to print something to the console whenever it is painted. This would help me identify exactly when these paints are being queued.
2) Identify when a CustomNode is put on the repaint queued.
If I answered 1 and 2, I might be able to figure out what it is that is binding all these different nodes together. Is it possible that JavaFX only works through global refreshes (doubtful)?
JavaFX script is a powerful UI language but certain practices will kill performance. Best performance generally boils down to:
keeping the Scene Graph small
keeping use of bind to a minimum (you can look at using triggers instead which are more performant)
This blog post by Jim Weaver expands these points.
I'm not sure as to the specific answers to your questions. If you examine the 1.2.1 docs you might be able to find a point in the Node documentation that you can override and add println statements but I'm not sure it can be done. You could try posting on forums.sun.com
This is a partial post. I expect to expand it after I've done some more work. I wanted to put in what I've done to date so I don't forget.
I realized that I'd need to get my IDE running with a full compliment of the JavaFx 1.2 source. This would allow me to put break points into the core code to figure out what is going on. I decided to do this configuration on Eclipse for remote debugging. I'm developing my FX in Netbeans but am more comfortable with Eclipse so that's what I want to debug in if I can.
To get this info into Eclipse, I first made a project with the Java source that my code uses. I then added external Jars to the project. On my Mac, the Jars I linked to were in /Library/Frameworks/JavaFX.framework/Versions/1.2
Then I went searching for the Source to link to these Jars. Unfortunately, it's not available. I could find some of it in /Library/Frameworks/JavaFX.framework/Versions/1.2/src.zip.
I did some research and found that the only available option left was to install a Java Decompilier. I used this one because it was easy to install into Eclipse 3.4: http colon_ //java dot decompiler _dot free.fr/ (<-- Please forgive the psudo link, I'm limited because I'm new)
This is where I am now. I can navigate into the Core FX classes and believe I'll be able to set break points and begin real analysis. I'll update this post as I progress.
I found a helpful benchmarking tool:
If you run with the JVM arg:
-Djava.util.logging.config.file=/path/to/logging/file/logging.properties
And you've put the following args into the file referenced by that arg:
handlers = java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = ALL
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
com.sun.scenario.animation.fps.level = ALL
You'll get console output that includes your frame count per second. For FX 1.2 it wasn't working for me, but it appears to be working for 1.2.1 (which was released Sept. 9, 2009.) I don't have a Netbeans that runs 1.2.1 yet.
You may want to read this article.
http://fxexperience.com/2009/09/performance-improving-insertion-times/
Basically, insertions in to the scenegraph are slow and benefits can be seen by batching up inserts
Related
I am using springboard in my application and have multiple task flows. So, whenever i switch from one feature to another feature a white screen flicker screen comes on task flow change among feature.This screen is also coming in MAF examples as well given by oracle.I want to remove that white screen coming for a short while on first time load of task flow
feature.Please reply me that how can i achieve it.
jdeveloper version : 12.1.3
maf : 2.2.2
Anand, we (I'm an Oracle employee) recently received a similar question internal to Oracle from Oracle Support on behalf of a customer. Presumably that customer was you and you already have an answer. Let us know otherwise.
Post edit in response to Anand's follow up answer.
No worries, here’s the details of the issue you’re seeing. I’ll attempt to describe why it's happening, and how you can potentially change your app to reduce this problem. While the description is long, it isn't actually that difficult to make these changes, it just takes a lot of words to explain!
In addition, I recommend you DO NOT make these changes permanent without a FULL ROUND OF REGRESSION TESTING. These changes will fundamentally change how your app is composed, so I can't guarantee it won’t break some of your logic. In order for you to make these changes and have confidence that nothing breaks, you also need to undertake a FULL ROUND OF REGRESSION TESTING before you make the changes, then compare it to the results of the post-change regression test, so you can differentiate from existing issues and new issues introduced by these changes.
So let's take a step back and describe why the issue occurs.
Firstly, as you’ve noted the issues happens the first time the application opens, and the first time you open a feature with an associated task flow. If you have a springboard with many features, as you skip between the features and they each start for the first time you will see this white flash for each (only the first time, not on each subsequent reopening). It also slightly delays the navigation to that task flow depending on the speed of your device.
Second, this issue will be much more noticeable on slower devices or in the Android emulator without HAXM as it is associated with a performance bottleneck. As MAF runs faster on iOS it’s hard to see this problem at all, and on modern Android devices in turn it's hard to see as it is too quick. As example on my older 1.5Ghz 2nd-gen 2013 Nexus 7 tablet I can see the white flash, most modern Android phones have a 2Ghz+ processor and I’ve not really noticed this problem any more. In turn as a developer you will see the flash more often as you will be continuously killing & redeploying the app which results in a restart of the app and the flash appearing the first time the app & each feature are opened/restarted again. (real users will see this much less often as they tend to stick to a couple features in most apps, and leave the app running in the background so the features are already initialized)
So why does the flash occur, and the associated delay in navigation?
When a feature is first called, MAF initializes a number of things in the background, including a classloader per feature. That initialization for whatever reason is costly in terms of performance, and during the processing can result in the UI being cleared which results in the white screen. I coin this effect the “white screen flash”.
Once a feature has been initialized, the speed underwhich it renders is much faster and you're unlikely to see the flash as everything is now safely initialized. In other words the problem is only noticeable for the first time a feature is rendered. If you re-open the feature, it will be too quick to see as the classloader is already loaded.
As we now know what is causing the problem, what can we do to avoid this assuming Oracle won’t fix or optimize the issue? (and in fairness the MAF development team did optimize MAF heavily in the 2.2 release).
Ultimately the solution is to reduce the number of features in your application, and ultimately (if possible) reduce this to just 1 feature so when the app starts you get the white flash once, but not again. But that begs the question, when MAF pushes you towards using features invoked by the springboard, how do you do this? Can we really reduce all the features?
If you think about your MAF application, you will typically have 1 feature for the springboard, then lots of other features for various useful parts of your app. Let’s call that the “springboard” feature (singular), and the “logic” features (plural).
The solution is therefore to:
1) move everything from your existing logic features (but the springboard feature), that is all the AMX pages, and other components such as managed bean in your task flows into 1 new single logic feature. For each of the preexisting logic features now embedded in that single new logic feature, create a wildcard navigation for each so they can be accessed and give each a name. eg. goFirstFeature, goSomeOtherNameFeature etc
2) for the current springboard feature it will stay, but we need to change how it works.
Typically customers create a springboard feature with a listview to navigate to their features (rather than use the autogenerated springboard). As our goal is to eliminate the logic features and replace them with the new single logic feature, the original springboard won’t work as it’s designed to call the other original individual business features (rather than our new super single logic feature).
Instead what we need to do is hardcode the ListView with ListItems to call each individual (logical) feature in our new single logic feature using the wildcards. Something like the following:
<amx:commandButton text="Go First Feature" id="cb1" actionListener="#{viewScope.myBean.goFirstFeature}"/>
<amx:commandButton text="Go Second Feature" id="cb2" actionListener="#{viewScope.myBean.goSecondFeature}"/>
This is backed by a bean with the following code:
public class MyBean {
private void doFeatureNavigation(
String featureId, String navigationFlowCase) {
AdfmfContainerUtilities.hideSpringboard();
AdfmfContainerUtilities.invokeContainerJavaScriptFunction(featureId,
"adf.mf.api.amx.doNavigation", new Object[] { navigationFlowCase });
}
public void goFirstFeature(ActionEvent actionEvent) {
doFeatureNavigation("package.name.of.new.single.logic.feature", "goFirstFeature");
}
public void goSecondFeature (ActionEvent actionEvent) {
doFeatureNavigation("package.name.of.new.single.logic.feature", "goSecondFeature");
}
}
Note how the code hides the springboard, then in context of the single business feature navigates to one of the wild card navigation rules you setup earlier in the new single logic feature.
3) if any of your existing logic features have AMX pages with command controls that navigate to any other logic features, you will need to change the code to call the wildcards:
<amx:commandButton id="cb5" action="goFirstRequest"/>
So it feels like a lot of explanation, but it really is 3 steps. Having done this then satisfactorily tested the app, you can start eliminating the redundant original logic features + task flows. Do not delete any AMX pages, pageDefs or beans, just delete the redundant features and task flows.
I’ve made a lot of assumptions along the way here in proposing the solution as I haven’t seen your app. But I hope this will give you a flavor of what the solution is.
And also you really need to think about is this a big problem and should you really undertake the solution. Personally with the latest optimized versions of MAF on Android, and faster Android devices I’ve not seen this problem for some time. Basically the white-flash is so quick that it’s just no longer a noticeable problem. In turn as real mobile users keep the app running in the background, they see this problem once, and won’t see it for sometime again until they kill the app and restart. So you need to think about are you fixing a problem that may not be seen by the majority of your customers.
I am a relative beginner at SSIS so I may be doing something silly.
I have a process that involves looping over a heterogenous queue and processing the objects 1 at a time. The process is currently being done in 'set logic' and its dropping stuff. I was asked to rework it in a looping manner, so that decision has been made for me.
I have chosen to implement queue logic in 1 package and the actual processing in another package.
This is all going relatively well considering...
I now have the process up and running, but its slow. 9 seconds per item. Clearly I cant present this solution. :-)
One thing i notice, 1.5 - 2 seconds of each loop are on the ExecutePackage Task in the queue loop.
I cant figure out how to get a hard number, I am using the flashing green box method of performance tuning. The other steps seem to be very fast. Adding indexes, changing sql to sps, all the usual tricks have helped.
Is the UI realiable at all with regards to boxes turning white/yellow/green? Some tasks report times in the progress tab, some dont seem to. So I am counting yellow time.
Should calling a subpackage be that expensive? 1 change i made was I change 'RunInASeparateProcess' to FALSE. I did that because the subpackage produces the following message otherwise:
Error: 0xC0012024 at Script Task: The task "Script Task" cannot run on this edition of Integration Services. It requires a higher level edition.
Task failed: Script Task
The reading i have done seems to advocate multiple packages. Anyone have any counter patterns? Should i stay the course? I started changing to 1 package. Copy/paste doesnt seem to work well w/ SequenceContainers. I would also need to recreate all the variables in the parent package. Doable, but im not sure that is the answer.
Does anyone know of any tuning resources/websites/books they would be willing to share.
Update - I have been tearing things down in an effort to figure out what the problem is. I was thinking it was the package configurations passing variable values. I dont think that is it. I can pass variables to another package w/ nothing in it and it is fast.
I can make the trivial subpackage slow by adding the two connection managers to it.
I suddenly realize I may be making and breaking a connection to both an Oracle Server and a SQL server in both the main package and then the sub package.
Am I correct in this observation?
Is there any way I can reuse the connection between the two packages?
When i google it, most of what i see is suggestions for passing the connection string.
UPDATE - I combined the two packages into one. This performance is not about 1.25 seconds per item, down from about 9. the only thing i can point to that changed is i am now reusing a single connection instead of making multiple connections.
Thanks, I appreciate any help you are kind enough to offer.
Greg
Once you enable logging, I'd suggest running the package from a command window using dtexec. While that doesn't perfectly duplicate the server environment, it does have the advantages of (a) eliminating BIDS as a potential performance issue and (b) being something you can do without jumping through change control hoops.
I am developing a WebGIS application using Symfony with the MapFish plugin http://www.symfony-project.org/plugins/sfMapFishPlugin
I use the GeoJSON produced by MapFish to render layers through OpenLayers, in a vector layer of course.
When I show layers up to 3k features everything works fine. When I try with layers with 10k features or more the application crash. I don't know the threshold, because I either have layers with 2-3k features or with 10-13k features.
I think the problem is related with doctrine, because the last report in the log is something like:
Sep 02 13:22:40 symfony [info] {Doctrine_Connection_Statement} execute :
and then the query to fetch the geographical records.
I said I think the problem is the number of features. So I used the OpenLayers.Strategy.BBox() to decrease the number of feature to get and to show. The result is the same. The app seems stuck while executing the query.
If I add a limit to the query string used to get the features' GeoJSON the application works. So I don't think this is related to the MapFish plugin but with Doctrine.
Anyone has some enlightenment?
Thanks!
Even if theorically possible, it’s a bad idea to try to show so many vector features on a map.
You'd better change the way features are displayed (eg. raster for low zoom levels, get feature on click…).
Even if your service answer in a reasonable time, your browser will be stuck, or at least will have very bad performance…
I’m the author of sfMapFishPlugin and I never ever tried to query so many features, and even less tried to show them on a OL map.
Check out OpenLayers FAQ on this subject: http://trac.osgeo.org/openlayers/wiki/FrequentlyAskedQuestions#WhatisthemaximumnumberofCoordinatesFeaturesIcandrawwithaVectorlayer , a bit outdated with recent browsers improvements, but 10k vector features on a map is not reasonable.
HTH,
Is there a trick to localize syntax errors? I occasionally run into this situation when editing existing code. Here's a latest example, do you see an efficient way to find the error? (I found the error already, but not efficiently)
http://yaroslavvb.com/upload/save/syntax-error.nb
May be, I am missing something, but in your example it was quite easy: once I put your code into a notebook and tried to run, the usual orange bracket appeared, and when you expand the messages, it states very clearly that the problem was in an empty parentheses in your vertexFormula function. In my experience, most of the time, the orange box gives enough hints.
Another great way which I use on a daily basis it through the code highlighting in Workbench. It immediately highlights syntax errors, plus you have a very powerful Eclipse-based navigation both for a single package and multiple packages. It might seem as you lose some flexibility by going to Workbench from an interactive FrontEnd development, but I found the opposite (or may be this is the revenge of my enterprise Java background): you still can have your notebook(s) in a Workbench project, where you do the initial development, but then they get attached to the project and a number of packages that you already developed and use. The transition from notebook to a package could not be easier, since you can continue use that notebook after you transfer the code into a package, and you don't even have to worry about loading the package, as long as you do it just once inside a project. Overall, I find the Workbench - based development much more fun as soon as your project goes over some critical mass (I'd say, perhaps around 1000 loc, but ymmv). But, complete new and independent chunks of functionality I still prefer to prototype entirely in the FrontEnd.
If you adhere to some specific coding standards in your code, or work with code which does, you might be able to develop some simple partial parser which at least breaks the code into complete chunks (function defenitions, Module-s etc, CompoundExpressions). Then, you could use ToExpression (say, Map it on a list of string code chunks returned by your partial parser), to see which piece of code is problematic (it will return $Failed on it). But if you use Workbench, this is unnecessary altogether.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have complex project without comments. The project is programed in Java but have more than one main class, use several .txt files like a template and use several .bat files. I don't know where to start and how to start discovering the project, because I need to make some changes in that project.
As with others I say this is a slow process.
However having done this in the past many times, this is my methodology:
Identify as many requirements that the code fulfils. This may give you the some reasons as to why certain things are the way they are when you look deeper. A common way of finding these is look for any tests that be available. The automated ones are best, but usually they're as missing as the comments.
Find the entry points to the code. These will give you places where you can poke the code to see how different inputs affect the flow. Common entry points are Code Loading 'Main' type functions, service interfaces, web page post backs etc..
Diagram the code. Look for tools that can build black/white box pictures of the code. For me this invaluable. I have on occasion printed out large listings and attacked then with markers and rulers. You're aim to create your own flow chart (mental or other wise) of the code flow.
Using the above (iteratively) build a set of outputs to the code that you think should occur, and add to these the outputs you may already know about such as logs, data files, database writes etc..
Finally if you have time, create some manual tests though preferably in automated test harnesses to verify the above. This where I start to involve the debugger to see detail in the code.
This methodology usually gives me confidence to make changes.
Note this is iterative process and can be done with portions of the code or overall as you see fit. I usually favour a top down approach to start with and then as I gain some insight I drill down till details become overwhelming and then I repeat. However this is just because my mind works in this way - you may be different. Good luck.
Find the main Main class. The starting point.
Start drawing a picture of the classes and the objects they own and the external entities they reference.
Follow all the branches until you can find a logical ending.
I've used UML reverse engineering tools in the past and while a visual picture is good, stepping through the code has always been the hardest and yet best methodology for me.
And, as you step through each piece you can add in your own comments..
I usually start with doxygen, turning on every extracting option (especially EXTRACT_ALL and EXTRACT_PRIVATE), and enable the SOURCE_BROWSER, HAVE_DOT, CALL_GRAPH and CALLER_GRAPH options (you also need to have dot installed). This gives good view of the software. For every function the calls are displayed and linked in a graph, also the sources are linked from there.
While doxygen is intended for C and C++, it also works with Java sources (set the OPTIMIZE_OUTPUT_JAVA option).
Auch. I'm afraid there is no speedy way to do this. Comment out a line (or two) -> test -> see what breaks. You could also put break statements here and there and run the debugger. That should give you some indication how you got there (ie. what the hierarchy between the classes is).
Hopefully the original developers used some patterns that you can recognize and make notes. Make lots of notes of everything. Start by trying to understand the high level structure and work down from there.
Be prepared to spend endless hours not understanding what the thing is doing.
Speak to the client and try to understand what the project is for, and what are all the things that it does. Someone somewhere had to put in some requirements for the stuff that's in there, if only in an email.
I would try to find the first entry point in the code closest to where you suspect you'll need to start making your changes, set a breakpoint, and start debugging. Check out the contents of local variables and work your way deeper as you get to become familiar with whats going on. Then, when you have a basic understanding of the area of code you're going to be working with, start fiddling with some small changes. Test your understanding of it. Try diagramming what you see happening. If you can do that confidently, you'll be able to decide if you need to go back and continue learning more about the code, or if you know enough to get done what you need to get done.
A start is to use an automated uml modeling tool (if you use eclipse you can use a plug-gin), and start creating UML diagrams of the various classes to see how they are related in a high level and visualize the code. This has helped many times
If there are log files being generated, have a look at it to understand the flow from the starting point (main class). Otherwise, put debug statements to understand the flow.
Ya, that sounds like a pretty bad spot to be in.
I would say that the best way is to just walk through the program line for line. Try to grasp the big picture in the code, and write alot of notes, both on paper and in comments in the code.
I would say, a good approach would be to generate documentation using javadoc or doxygen's class diagram feature, then as you run the code traverse through the class diagrams generated using doxygen and see who calls what. This works wonderfully for me everytime i am working on such a project.
I completely agree to most of the answers posted.
I can add to use a development tool that reverse engineering the code and create a class diagram, to have an overall picture of what is involved.
Then you need patience. But you will be a stronger and smarter developer when you'll get through...
Good luck!
One of the best and first things to do is to try to build and run the code. It might sound a bit simplistic but the problem when you take over undocumented code is that you can't even build it and run it. When have no clue were to start.