My JavaFX application shows a Linechart which is populated from an ObservableList which updates in realtime from underlying data model. This was working to an extent except I was getting ConcurrentModificationException due to different parts of the application accessing the List at the same time. Reading around, I saw that the List needs to be CopyOnWriteArrayList or ConcurrentHashMap to avoid that exception but it also needs to be ObservableList to load to LineChart. I later find that CopyOnWriteArrayList does not perform that well compared to ConcurrentHashMap. But then it seems counter-intuitive to implement the ObservableList using a HashMap. How then should one meet the combined needs of Thread safety and performance while using ObservableList?
Related
Let's say I want to load an FXML document to be used somewhere in my application. As far as I'm aware, there are two ways of doing this:
Call the static FXMLLoader#load(<various resource args>) method.
Initialize an FXMLLoader (with the resource location), and then call load() on that instance.
My question is what exactly "loading" an FXML document does here.
Initially, I assumed the static method would do an entire parse "cycle" on every call, and that creating an instance would allow multiple loads to take advantage of some kind of preprocessed representation, but documentation for the non-static load() method just states;
"Loads an object hierarchy from an FXML document. The location from which the document will be loaded...", which sounds like the document is loaded on every call.
I'm using JavaFX 17.
After spending a fair bit of time with the source, I feel I can give a pretty good overview of how FXML loading functions behind the scenes. That being said, I can't guarantee that there isn't anything I didn't miss. I've thoroughly looked over quite a bit of code I thought to be important, but most isn't all, and I may have simply not noticed something.
This answer should be valid for JavaFX 17.
As a TLDR answering the main concern of my question: As far as I can tell, no information is cached across load() calls, regardless of whether you use the static or non-static versions. That being said, the non-static calls will still give you a slight performance gain, the fastest of which is the load(InputStream inputStream) overload, which (in addition to skipping some argument processing) will prevent the loader from opening a new InputStream on every call.
I've built a call graph (CallGraph Viewer) showing important parts of the FXML loading code in order to make it a bit more digestible.
This is easily the most likely part of my answer to contain inaccuracies. To generate this graph, I simply copied the FXMLLoader code into eclipse and generated connections for parts of the code I deemed important. Unfortunately, the plugin doesn't always correctly parse code containing missing imports, requiring me to write in definitions for a couple of classes, but I left most alone. Additionally, the initial result was incomprehensible and needed a fair bit of manual cleanup, a large portion of which was done simply based on whether I thought something sounded useful or not.
If you are unfamiliar with eclipse's icons, documentation can be found here (make sure to zoom the image, or open it in a new tab, or I doubt you will be able to see much).
Yes, there are three processEndElement() methods with the same signature, they are overridden methods in subclasses of Element.
If you're wondering what I spent all that manual cleanup time on, try not to worry about the individual methods, more the overall structure.
Here's my breakdown of this mess as a step by step recreation of what happens when load() is called:
The application calls one of the public load() methods. This simply calls a matching loadImpl() overload (static if the load() call was static and vice-versa) with the provided arguments. All existing loadImpl() overloads also ask for the class which called them, which the method attempts to provide with a java.lang.StackWalker. No additional processing is done.
After passing the public interface, execution is routed through a hierarchy of loadImpl() calls. Each overload just calls an overload with one more argument than itself, passing on its own arguments and giving null for the missing one (except in the case of a missing charset, which is given a default value).
The more arguments you give to load(), the farther you start in the hierarchy, with non-static versions beginning after the static ones. If you call one of the static overloads, an instance of the FXMLLoader class is created at the final static loadImpl(), which is used to continue onto the non-static calls.
Once reaching the non-static loadImpl() calls, things begin to get interesting. If using the load(void) overload, an InputStream is created based on arguments set when the FXMLLoader instance was initialized, and is given to the next stage in the hierarchy as before. At the final (non-static) loadImpl() (which can be called immediately using the load(InputStream inputStream) overload; this is the fastest method I know of to get from the initial load() call to XML processing), we finally exit the loadImpl() hierarchy, and move to XML processing.
Two things happen here:
a ControllerAccessor instance is given the callingClass argument passed up the loadImpl() hierarchy. I can't exactly explain how this class works, but it contains two Map's; controllerFields and controllerMethods, used in the initialization of controllers.
clearImports() is called, clearing packages (a List) and classes (a Map), both used in further XML processing.
The four variables here (except for maybe the controller ones, I'm a little iffy on them) act as important cache data for the backend XML processing cycle. However, all are cleared between loads (there is no logic controlling their execution, if the load succeeded, the cache data will not have survived), so using an FXMLLoader instance will not improve performance due to data caching (it's still worth using one, however, as the non-static calls skip much of the loadImpl() hierarchy, and you can even reuse the InputStream if using that particular overload).
Next, the XML parser itself is loaded. First, a new instance of a XMLInputFactory is created. This is then used to create a XmlStreamReader from the provided InputStream
Finally, we now begin actually processing the loaded XML.
The main XML processing loop is actually relatively simple to explain;
First, the code enters a while loop, checking the value of xmlStreamReader.hasNext().
During each cycle, a switch statement is entered, routing execution to different process<X>() methods depending on what the XML reader encounters. Those methods process the incoming events, and use an assortment of more "backend" methods to carry out common operations (The 'backend XML processing' section of the call graph is only a small portion of the actual code). These include methods like processImports(), which calls importPackage() or importClass(), in turn populating the packages and classes caches. Those caches are accessed by getType(), a backend method used by many other processing methods.
Additionally, I think that some part of controllers is "assigned" during this stage; processEndElements(), for example, ends up calling getControllerFields() or getControllerMethods(), which access the aforementioned controllerFields and controllerMethods caches, but also sometimes modify them. That being said, the call graph gets a bit too deep for me to easily understand at this point, and those methods are also called later, so I can't be sure.
After XML processing, a controller (controllers? see comment below) is initialized. You can read about controller initialization a bit in James_D's answer here, but I don't have much to say about it, as this is the section I am least confident in understanding.
That being said, it is interesting to note that this code is out of the previous while loop; only one initialization method is called. Either what seems like one call is actually multiple (which is definitely possible; the initialization "method" called is returned by controllerAccessor.getControllerMethods() and "it" is called using the MethodHelper JavaFX class), or only one controller is initialized here (assumedly the controller for the root node) and the others are initialized during parsing. I'd lean towards the first possibility here, but that's based purely on intuition.
Finally (and if you're still reading by now, consider me impressed), we enter cleanup. This stage is super simple;
The ControllerAccessor has its "calling class" variable nulled, and its controllerFields and controllerMethods caches cleared.
The XmlStreamReader instance is nulled.
The root node is returned, and thus the function exits.
Thanks to #jewelsea for links to other answers and for recommending I look at the source.
I am new to android and java and working on an app that has a few remaining problems that I haven't resolved yet.
I have a main activity that is a viewPager, with each page being a fragment. If the 4 fragments 3 are extended from ListFragments and one from PreferencesFragment.
The ListFragments have CursorAdapters to get data to and from SQLite databases through providers.
I am able to get data into the database, insert, modify and query the data correctly and fill the list views ok.
My preference setting are to choose different ways of viewing the data in the database.
Not knowing how to do this, I have implemented a process where I modify the cursorLoader query to the provider with a number of different choices of the "WHERE" clause. I have worked out the logic for the preferences as they exist now, implemented the code but had some difficulty finding what to try to trigger the refresh of the ListView.
Since the "dataset" hasn't really changed, no trigger can come from there, plus that would just use the same cursor as it currently exists to run the query again and return the same results (or be smart enough to know that it doesn't need to run).
On Stack Overflow I did find a couple of references to a similar implementation that suggested reStarting the cursor loader, which would then on the reStart read the current values in the stored Preferences file, create a now modified WHERE clause that will show the sub-set of data as specified in the preference settings.
In testing the app now, even with the reStart of the cursorLoader, the ListView isn't getting refreshed.
The only time I can get it to work right is restarting the app. If I stop the app and restart it, the new values are used and the ListView presents as the preferences dictate.
In looking through Stack Overflow and the Android site, I did find another set of APIs that might have been a more natural fit for what I am trying to do, namely the Filter APIs.
First question then would be, did I go in the wrong direction on how to control the "filtered" view of the datbase. Is filtering a better approach and a recommended way of
doing what I am trying to do?
Second question would be related to the fragment lifecycle of my ListFragments to achieve this CursorLoader update.
Thanks for any input on the topic.
-Dan
Found my problem here.
Two things, the way I am trying filtering is working and from what I have seen in the
Android development site, a reference there indicated that the filtering capability is
already implemented in the CursorAdapter, CursorLoader classes I am using.
When my preference settings changed, I did a reStart of the cursorLoader, but had restarted the wrong one.
Problem solved. Any input on is there a better way would be appreciated.
Regards, Dan
I have a Qt application built on top of a library that manages an SQL database. I have several models (QAbstractTableModel and QAbstractListModel subclasses) that represent different tables in the database, and I have a few associated views.
The models typically have a cache of data from the database and a pointer to a database object that they can use to refresh their caches as needed. I have implemented insertRows, removeRows, and setData so that they attempt the database operation in a transaction, and then if it succeeds, they update the cache inside beginInsertRows()/endInsertRows() (or remove as the case may be) so that the cache doesn't change outside of the begin/end pairs and everything stays in sync.
So far, so good, and everything is working fine. If all changes to the database came from the GUI, I'd think this was a nice solution.
The problem is that some database operations involve changing tables that are represented by more than one model. To the application, it looks like table updates that originate in the database layer. I could have the database layer call up into the model layer whenever it wants to make a change (which is what I'm doing now), but I don't like the way it exposes the lower-level database layer to Qt models. It also has the problem that the models need to make their changes inside a transaction so they know when the operations succeed or fail, and going through the model layer would preclude the database layer from enclosing multiple updates in a transaction.
Alternatively, I could make the caches in the models be the "real" data. I could then change the underlying database and inform the models after the fact, at which point they would update their caches. I think this works fine for small tables, but since it would mean caching the entire table, I don't think it works for large tables.
My thought is that this is a common enough problem that may be some kind of known best practice for this. Is that the case?
Thanks.
I'm working with the ASP.net Web API for a simple REST api. I'm using Linq for my data access layer and was newing up a new linq datacontext for every api call. But it seemed a bit resource intensive to create a new data context for every call, so I started thinking about moving the datacontext to single application-level variable which would be instantiated in the global.asax.
Each api function is simply performing straightforward CRUD operations on a single table. I understand there are some concurrency issues if with this approach. But in reality all tables are partitioned by users so 2 different users could not update or delete the same rows on any table. Also since its an api I'm calling datacontext.submitchange() after every change so there any single user could update the same row at the same time.
So beside the concurrency issue, are there other concerns which managing a datacontext at the global level vs. instantiating on every api call? Are there other approaches that might also achieve the performance/resource benefits of the application-level instantiation?
I believe you can define your data context to be a global variable. If you are absolutely sure that in the future you will have no problem because of this, then you can do this.
However, before you make this change may I suggest that you benchmark your application to find out exactly what is eating your resources? Are you absolutely sure that your data context is guilty? What if something else eats your resources?
You should identify your problem first and only then start to optimize.
I'm trying to find memory leaks in a fairly large Flex application and I'm tired of using the paltry tools Flash Builder makes available.
Specifically, I want to analyse the relationships of objects in memory, using the same information Flash Builder's tools appear to have access to. I.e. which objects are in memory, and which objects they have references to, and have references to them. Given that information, I want to construct a directed graph whose nodes are live objects and whose edges are references from one object to another. From there I want to search for dominators, which should be a good indication of which objects are leaking.
I believe Eclipse does something similar for Java.
Unfortunately, Flash Builder only allows the export of its captured profiling data in a binary form that's only parsable by Flash Builder. Rather than try to reverse engineer their output I decided to try to capture the data myself, since they make their profiling API available in the flash.sampler.* package.
So far I've managed to collect the objects that are currently live in memory, get their allocation traces, and references to the objects that I can inspect, which is most of what I need. But I can't figure out how the FB profiler traces back-references to the GC root. The only way I can see to do it is to inspect every object in memory, and for each object inspect each of its properties, and so on, until I find a chain to an object classified as "root" level. But since I can only follow references on publicly visible properties, it's entirely possible I'll miss lots of references that prevent garbage collection.
How does the Flash Builder profiler do it?
My suspicion is that it doesn't just use the sampler.* API to capture information, but supplements that with queries performed through a debugger connection, which is probably out of scope for my work. But in the absence of any way to verify that, I'm hoping it's possible using only the sampler API.
Actually in IMHO if Flash (Flex) Builder's memory / performance tooling is paltry then you aren't using it right. The key to understanding the tooling you have available - has been available since the 4.0 SDK and and I've been using it for every project I've been assigned to as the 'runtime-analysis-guy'.
Live View:
We all know about this one, it gives you a "live" view of what's currently available. While the current instance count is useful, what's even more useful is the cumulative. This helps track down the errant methods which create way too many objects.
Loitering Object View:
You probably aren't using this one, but trust me once you do, you won't go back. With this it helps to have clearly defined small screen / application states (eg. 1. A starting point, 2. The ability to create a dialog 3. A closing point which is the same state as 1). In your application, get to the place you want to test. Then click the memory snapshot function - the "colored lines icon." Now in your application, run through steps 2 and 3. Go back to the profiler, and click this again. Here you can now either terminate or pause your application. Select both memory profiles and click the loitering object function - "the green icon." In theory this list will be empty, but it won't. This shows you what objects have been marked for [sweep] but not [reap]'ed.
D-Click any object and this gives you a detail view with a list of every reference that still holds onto this object. I'll give you a hint right now, if you haven't created a deconstruction process in your application (eg IDestroyable interface), stop right now and go back and do this. You must assign null to every object that is not a complex primative. This means every class, every array, vector, eventlistener and so on.
The sampler package is the only thing the tool uses as far as I'm aware - after all the tool doesn't inject any code into your application at the time of invocation. It's a comparison of all objects with the NewObjectSample and the DeletedObjectSample, and looking at the getSavedThis() going back up the prototype chain (this should return an object where you can call the getSavedThis() on it and so on).
http://help.adobe.com/en_US/flashbuilder/using/WS6f97d7caa66ef6eb1e63e3d11b6c4d0d21-7edf.html
Hope this helps.