# Optimize Rules to Speed-up Rename or Mapping

This document explores how renaming and mapping work and provides strategies to improve efficiency and performance, reducing system load, and improving overall performance through rule optimization.

There are two primary matching routines used: exact matching and glob matching.

Exact matching works as expected, requiring the input data to match the predefined criteria perfectly.

In feature-rename.map, for example, matching is performed on a concatenated string composed of the following four elements:

• Feature Name
• Daemon
• License Manager
• Vendor License

MAP: Architectural Desktop R3.3 
40100ARCHDESK_3_3F\adskflex\Flex\server1;adskflex

During the matching process, these four values are combined from the data, concatenated together using the \ character as a separator, and then compared against the entries in the map file.

A key advantage of exact matching is its speed and efficiency. The process is simple and quick since it directly compares the data string and the mapping entry. There's no requirement to analyze complex patterns or consider multiple possibilities—the system either identifies an exact match or it does not.

Exact matching helps reduce processing time, minimize system resource usage, and enhance overall performance in environments that manage large datasets.

While exact matching offers speed, it can be challenging to maintain in dynamic environments. Any minor change in the feature name, daemon, license manager, or vendor license—such as a version update or formatting change—can cause the match to fail. This means the map file must be continuously updated to account for even the smallest modifications in the data.

Moreover, as the number of features and variations increases, maintaining exact matches becomes increasingly complex, leading to higher administrative overhead. There's also a greater risk of errors if updates are overlooked.

While exact matching offers speed and efficiency, it comes with a significant maintenance burden. Any minor change in data—such as updates to license servers, daemons, or vendor information—requires corresponding updates to the mapping file. Managing multiple license servers often leads to repeated configuration entries, making the process cumbersome and prone to errors. To alleviate this overhead, many users prefer using globbing (wildcard-based matching) to define mapping entries, as it offers greater flexibility with less manual upkeep.

MAP: Architectural Desktop R3.3 
40100ARCHDESK_3_3F\*Flex\*

Globbing and regular expression (regex) matching present a performance trade-off. Unlike exact matching, which allows for a single lookup, glob and regex matching require iterating through all entries until a match is found. For entries not present in the map, this means examining every value, which can further degrade performance.

That said, not all regex matches are created equal. Certain patterns are more efficient than others. Specifically, regex evaluations benefit from faster shortcuts when the wildcard or pattern match appears at the end of the rule.

MAP: Architectural Desktop R3.3 
40100ARCHDESK_3_3F\*

It's important to recognize that you don't need to match every original field individually when combining multiple values into a single string. For example, even though we're concatenating four values in the previous example, creating separate rules for each one is unnecessary.

Consider this rule:

MAP: Architectural Desktop R3.3
40100ARCHDESK_3_3F\*\*\*

This pattern will slow down matching because it is no longer a simple tail regular expression. Adding unnecessary separators complicates matching without providing any benefit. To optimize performance, simplify the rule to:

MAP: Architectural Desktop R3.3
40100ARCHDESK_3_3F\*

In situations like this (specifically for Autodesk), the Feature Name is almost certainly unique and not shared with other applications. This suggests that matching based on the license manager type (e.g., Flex) may be unnecessary. However, this assumption should be made cautiously and verified for each scenario.

A simple approach is to rearrange the fields so that only the last part of the rule utilizes globbing. While it may be convenient to omit some fields, including them can enhance the efficiency of the matching process.

For example, Autodesk features generally exist within a single daemon. This enables us to organize the rule as follows:

MAP: Architectural Desktop R3.3
40100ARCHDESK_3_3F\adskflex\Flex\*

We maintain better matching performance by placing the License Manager (Flex) near the end and keeping a single wildcard at the tail.

If filling in the missing in-between fields isn't practical, reordering the fields in the map file is an alternative approach. However, this will require updates to all filters referencing the map file, making it a slightly more involved process.

Let's say we want to match on the feature name and license manager, but not on the daemon (or vendor license). In that case, the map file should be structured like this:

MAP: Architectural Desktop R3.3
40100ARCHDESK_3_3F\Flex\*

For instance, in the olap-group-concurrency.xml file, locate the following section:

704| <Object>
705|     <Name>set-value</Name>
706|     <Description>set value feature</Description>
707|     <Value type="String">#1:var6=$feature . '\' . $daemon . '\' . $license_manager. '\' . $product </Value>
708| </Object>

The Value parameter should be:

704| <Object>
705|     <Name>set-value</Name>
706|     <Description>set value feature</Description>
707|     <Value type="String">#1:var6=$feature . '\' . $license_manager. '\' . $daemon . '\' . $product </Value>
708| </Object>

This rearrangement enhances matching efficiency but requires adjustment to all related filters accordingly.