LAE

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: mwillett

Hi,

I have a brg file that is now about 2.5Mb (so not big, but large compared to other brg files I've created). It does have a lot of the charts from Inflow reporting which I assume is the reason for the size.

I've now noticed that the application is starting to run slow (not the data through the graph, just when I want to alter the graph to, for example, add/change/move nodes etc). Is there anyway to see how I can speed this?

Mike

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: Tim Meagher

Hi Mike,

The chart images themselves are not saved into the BRG format.

However, adding a lot of charts will significantly increase the size of the BRG as you noticed.

The reason for this is that the inFlow nodes themselves contain many sub-nodes in order to do data cleansing, pivoting, sorting (display order & other), filtering, invoking the charting engine, visualizing etc. As more nodes are aded to a graph, the performance will deteriorate somewhat.

We have made numerous improvements over the last few releases specifically to deal with this problem. Hopefully getting the latest LAE release will significantly improve the performance for these cases where you are noticing degradation.

On that point - what version of the LAE are you using?
In both LAE 4.5.1 and 4.5.2 we added a number of performance enhancements in this area.

I can double check on the exact numbers, but as of LAE 4.5.2, I believe that graph navigation, and insert, delete, cut, copy & paste of nodes should not really involve a noticeable delay until you have more than about 10,000 nodes in the graph. Graph load time has also been improved in LAE 4.5.2.

One of the remaining performance bottlenecks in BRE in the latest version is that the maintenance of the Undo lists in BRE is quite expensive. We are hoping to address this in the future.

The way this feature is implemented at the moment makes it a "dumb" undo - but it is very safe. Fixing this will likely involve optimizing exactly which state information is saved for each undo step, (rather than the current - "save it all" operation) - as such, it is a significant undertaking to identify all of the items needing saving, ensuring that these are correctly saved, and a whole lot of QA to make sure we got everything right. As such, this did not fit within the timeframes for the last releases where we did focus on a number of performance improvements.

So... if you have the latest version (4.5.2) and are still seeing these issues and they are causing you significant headache, then there is one - risky - option that is available to you....

Within BRE, in Tools->Preferences, you can set "Max Undo Levels" to 0.
This will mean that Undo operations are never available, and Ctrl+Z and Ctrl+Y won't work within BRE.

Like I said, it is a risky option - and not recommended for obvious reasons - but if you are only concerned about performance, this is an available option.

Another note : There are existing enhancement requests that we hope to look at in future releases to ensure that the graph file size does not grow as rapidly as what you are seeing. Simply changing the method in which the graph is serialized to disk won't have any effect on BRe performance outside of the time taken to load and save graphs.

However having large BRG files has other effects on disk usage, and ability to easily locate diff's in BRG files when placing them under source control, so this is something we are monitoring and evaluating for future releases.

Regards,
Tim.

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: mwillett

Thanks Tim,

I am on 4.5.2 but it's not a major issue so I can wait for the changes and upgrades you make over time.

Mike

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: snbkumar

Hi Tim,

I thought I could use this nice thread instead of starting a new one as my query is related to node quantity impacting performance.

Given that the reduction in node count will marginally increase the execution time, can you provide the list of single-nodes that can be used to overcome the functionality provided by a group?
Example: I was trying to implement a functionality in a join node to mark a certain field1 as "XXX" incase field2 is "A". Else if field2 is not "A", then i leave field1 as it is. For this i split the data into two outputs using a filter based on field2 value and then in the filter I did a override of field1. Then I did a Cat and emitted the merged output.
To me this is a simple work in PL/SQL where I write in fewer lines without impacting performance to a big deal.

I am still learning the aspects of Scripting in Lavastorm and would greatly appreciate your help.

Thanks,
Bharath Kumar

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: Tim Meagher

Hi.

If I understand correctly you should be able to do what you want in a Filter node using a Script like the following:

Tim.

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: snbkumar

Hi Tim,

Thanks. That worked. Coming to my earlier question, is there a way to do performance assessment for graphs and increase performance by changing the way the node works?

Eg: Agg node has an option to "Verify Inputsorted" - can this be set to False, so that verification time reduces?

Thanks,
Bharath

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: Tim Meagher

Hi,

Sorry for the delay in responding.
I did some tests with the Agg & Agg Ex nodes operating on 20 million records and didn't see an performance different when switching off the "Verify Inputs Sorted" parameter.
You can set this to false, however that simply means that the node will not error if the data is not in the order specified in the GroupBy parameter.

Generally you want your data to be sorted in this order, so I don't think there is any real benefit here for switching this parameter off unless you have specific needs for out of order data...
Off the top of my head, I can't think of what these might be at the moment.

In any case, there are nodes which have parameters which would change the performance characteristics.
For instance, on the X-Ref, Join Inner, Join Left, etc nodes, if you have sorted your data prior to the join, you wouldn't want to specify that the data needs to be sorted within the join.

However, each node documents the parameters it defines, and explains what the parameters do, so you really need to look at it on a node by node basis, and when constructing your graph ensure that you are using the nodes in the manner that best suits what you need both from a functionality and performance perspective.

In general, the biggest performance improvements that can be made through sensible graph design.
Some reasonably common cases of things that can impact performance are:

• re-sorting data that has already been sorted on the same keys
• performing inefficient joins that would result in a cartesian product of the input data sets (in cases where this isn't required)
• maintaining all fields/records through the entire graph when you only care about a subset of the fields
• inefficient BRAINscript, Java, or Python code in different nodes
• unnecessary use of clocks, or dependencies in data streams that lead to limit the parallelization of the graph.

In some cases, there is a trade-off between optimizing your graph and writing a graph that is maintainable & easy to understand.
For instance, rather than having 10 filter nodes performing simple operations, you may be able to write a single filter node to do the same thing.
However, if the BRAINscript code within the filter node becomes so complex that it is no longer easy to understand the purpose of the node with a quick glance, then often this is the sort of optimization that will lead to more problems later. This is particularly true if the person who originally wrote the graph hands it over to someone else to maintain/work on.
It would also remove the ability to see intermediate results and reduces the traceability of the graph.
However, if you had a case with 10 filter nodes, where each node renamed a single field, then putting this all into the one filter node which renames all the fields would not impact readability, but would improve performance.

There are also other things to consider, with regard to the execution time of the nodes.
For instance, a sort will normally take longer than a filter node (it's a more complex operation).
Therefore, discarding various records prior to a sort node would make more sense than doing this directly after the sort.


Tim.

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: snbkumar

Hi Tim,

Thanks a lot. The wait for your reply was worth it. I understand your point that the node count reduction can improve performance and most importantly, limiting the fields in the data helps.

Is there a performance tuning approach that we can follow with respect to Brainscript?

Regards,
Bharath

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: Tim Meagher

Hi,

There are numerous things that can be done.
It's a scripting language, and as with all scripting languages you are really free to write as efficient or inefficient code as you like

Probably one of the easiest to overlook, however, is that when writing Brainscript code in filter and agg nodes, if there are complex calculations that you only need to do at the start, or end of an execution iteration, you should do them within an if (firstExec) or if (firstInGroup) or if (lastInGroup) block.
This just means that the calculation won't need to be re-evaluated each time.

Tim.