Expression rule

The answer lies in whether you think the fetch of the data needs to be re-used in other contexts or you will always use the manipulated version of the fetched data.

Does creating more objects impact the application performance .i can create one expression rule and make use of it wherever i want (expression rule will be complex )  or i can create multiple expression rules to make the code more easily understandable. which way i should follow as best practice

The performance overhead (which essentially can be attributed to passing pointers to the data you're processing) will be minimal. The benefit from "creating more objects" will only be reaped if those objects are well encapsulated and have high "cohesion" and low "coupling".

Generally speaking I'd say you can create as many expression rules as you need without impacting performance.  What it will impact is ease of finding the one you actually need if you create many extra ones. 

The best practice in my experience is to carefully find a balance.  You will want to think in terms of making your code "modular", i.e. chunks that you anticipate will be useful in several different places (without the burden of re-creating it in those places), should be saved as their own objects.  If you don't anticipate this will be the case, then sometimes it will be fine to just have a big, complex rule that handles everything internally.  Over time you'll notice if/when you're recreating the same logic over and over again, in which case you can go back and encapsulate reused logic in helper rules, though doing this afterwards can be more of a burden than doing it up-front when possible.

Generally speaking I'd say you can create as many expression rules as you need without impacting performance.  What it will impact is ease of finding the one you actually need if you create many extra ones. 

The best practice in my experience is to carefully find a balance.  You will want to think in terms of making your code "modular", i.e. chunks that you anticipate will be useful in several different places (without the burden of re-creating it in those places), should be saved as their own objects.  If you don't anticipate this will be the case, then sometimes it will be fine to just have a big, complex rule that handles everything internally.  Over time you'll notice if/when you're recreating the same logic over and over again, in which case you can go back and encapsulate reused logic in helper rules, though doing this afterwards can be more of a burden than doing it up-front when possible.

Agree on no performance degradation expected from increased object counts.  Our overall 'object' count excluding documents is 1,168,616 - I have not seen any related performance issues, and do not expect any.  We have an additional 3,015,118 documents stored in Appian.  Our overall platform is something like 9 TB.

Thanks mike

Thanks chris i was thinking like increasing objs will impact performance