Who rated this post

In my opinion, inline is more about ease of management in the long run.  When researching my last book, I prepared two different policy packages that accomplished exactly the same goals.  One was ordered (one feature per layer), and the other was inline with sub-rules.  I examined the compiled Unified Policy INSPECT code for both, and there were only minor, cosmetic differences. 

So, I doubt there is much of a rulebase lookup performance difference between inline and unified, with one big exception: the key thing to watch out for, regardless of ordered vs. inline, is ensuring that you only have the Firewall blade enabled in the top or first layer.  So, for inline the top/parent rules are Firewall blade only, and only match simple services (port numbers), then in the sub-rules (or second separate layer in the case of ordered) is where you enable APCL/URLF and call for applications and categories.  This will help SecureXL accept templating optimize the overhead of rule base lookups.  See the following thread for my explanation of this: 

https://community.checkpoint.com/t5/General-Topics/Clarification-Needed-on-fwaccel-stat/m-p/252954/h...

As long as you adhere to this recommendation, the difference in rulebase lookup performance on the gateway for ordered vs. inline seems to be negligible, at least as far as I can tell.

If you have a very large ordered policy, it was likely upgraded from an earlier release to R80+, as only the equivalent of ordered layers was possible prior to R80.  So, if that existing large ordered policy is working well and you understand it thoroughly, is there some burning, urgent need to convert it to inline?  I would personally say NO there is not, as doing so is a manual process and you will probably hit some bumps along the way.

However, if you are implementing a brand new policy package for a new firewall or site, ABSOLUTELY start from the beginning with inline.  In the long run your policy will be shorter and easier to understand.  This is also a great time to look at using Security Zones instead of big groups of networks for rule matching, and the use of "network defined by routes" for the new gateway anti-spoofing configuration.