Community
Participate
Working Groups
Early TPTP results show that the biggest memory hogs are the many instances of DublinCore and URIToIdentifiable Reduction in instance size and/or number of instances would help keep the footprint of STEM down to a reasonable size.
Created attachment 59585 [details] Email containing a TPTP screen shot and comments from Dan.
This isn't an easy one to just "fix". The URIToIdentifiable is a class generated by EMF as part of the EMap it generates that allows Identifiables to be found by their URI and their TypeURI. Maybe with more use of the model we will decide we don't need the mapping(s), but right now removing them would be a big deal. I had a preliminary look at removing the TypeURI mapping and found places in the disease model plugin where it is used to find population labels when a graph is decorated. Removing it would break that (which is being used properly). Let's look at this one later after we look at some other ways of reducing the memory foot print.
Created attachment 60084 [details] mylar/context/zip
LATER/REMIND bugs are being automatically reopened as P5 because the LATER and REMIND resolutions are deprecated.
Assigned to Stefan
Every Edge and every Label in STEM has a dublin core object attached to them. It doesn't really seem necessary. Nodes uses dublin core attributes to store things like spatial maps, so we can't get rid of those. This is an old defect, let's discuss it on the developer call.
Per discussion on the call, we will look at Labels first to see what impact removing the Dublin Core object has.
I would suggest - if possible and in the long run - to restrict the usage of the dublin core to the task to store "bibliographic" information necessary for documentation, e.g. who generated it, what data source was used, additional information. If one needs to attach specific information to an object (e.g. spatial information) I would prefer to have specific variables. So that if one needs these values at some place in the program for a certain type of calculation (e.g. polygone information for the visualisation, time information for plausibility checks etc.) the user has to make sure that the information is supplied. So to come up with a suggestion for the memory issue - wouldn't it make sense to implement the same hierarchical concept that is currently used for models and graphs for variables that should be assigned to objects like nodes and edges as well? E.g. then one could attach a dublin core object (with bibliographic information) to a graph (as the hierarchy level that integrates nodes and edges) and the user decides whether there is the need to attach specific doublin cores to the hierarchies below, e.g. in case of nodes a dublin core where the data source is specified. If I want to associate specific values (area, spatial, population size etc.) to each node, then one would assign them as single variables to each node or also on the higher level if for all nodes the values should be the same. I really don't know if this idea helps! Maybe we can discuss it on the next weekly call again.
