I'm not sure why you changed your original reply to this, but I can answer this one more directly. No, I don't have characters that can wear gear that has a CP value greater than 160, nor does that gear exist yet; you know this. The issue was and is that the charcp() function as I originally imagined it only returns the effective CP level of the character, a value that is worthless when trying to determine whether a gear item is above or below the "gear CP level" of a character. Here's a thought experiment:

I have three characters, one that is CP100 and another that is CP300. I have a piece of CP160 gear in the bank. You and I both can easily see that it will be "low level" to NEITHER of those characters. With my original Low Level rule,when each character visits the bank, how is that piece of gear categorized?

The answer is that it's categorized as Low Level for ONE of them, the CP300 character, which is clearly wrong. Why does that mis-categorization take place? It's because of this test:160 < 300

Do see the problem and why I had to add the extra if statement to the function? Any character whose CP level is greater than 160 must have its CP level as reported by the ESO API capped to a range of 0 to 160, else the above test returns an erroneous result.
.

If the item is CP 160, how can it possibly be lower level than the current character? Do you have characters that can wear gear >CP160?

I think you've forgotten the reason why I asked for those functions and altered the rule in the first place: I want the Category to match gear that is a lower level than the current character. Testing against a CP value of 160 makes it no different than the original rule, which didn't need the extra function(s).

What I thought you were going to offer was an elegant means to eliminate if cp > 160 then cp = 160 end from the charcp() function itself? I'd rather not be maintaining my own private fork of AutoCategory just for one sentence of code. For my rule to work, either that must remain in the charcp() function or an efficient equivalent needs to be inserted into the matching rule. I don't know how to implement that.

I will try to look into this, but I am not the original author of Auto Category and may not be qualified to resolve this type of issue. Guild Banks work OK for me, but are definitely a little slower to open. If you're mainly having issues with Guild Banks, just remove all the rules from your Guild Bank settings. That will work around it for now.

Just add an explicit check for whether the item is 160 with the cp() function.

Originally my altered Low Level category rule looked like this:
However, while I was trying to figure out why it wasn't working as intended I simplified it to this, which apparently (with my modification to the function) produces the same result:
I'm not sure why that works. My original rule might have been too pedantic because there are things I don't understand about LUA or the ESO API.

I've been willing to endure the "lag" you describe (which really isn't lag in the correct sense) because being able to categorize everything is crucial to me, but your complaint is not invalid. If one were to take AutoCategory and strip out all the custom programmability and leave just a one-size-fits-all cookie-cutter version, it might result in reduced computational burden that would please you. I wouldn't find any use for that one-size-fits-all version, though. The time it saves me in making sense of virtual containers full of hundreds of virtual items - once I've been able to customize it to my workflow and way of visualizing things - is well worth the extra seconds I wait for transactions to finish.
.

I have been happy to use autocategory. But as soon as I began dealing with guild banks I had to stop. The performance degradation is simply to bad. It's literally like 500% increase in time spent waiting, and when opening the guild bank if there is more than 300 items in there it's just horrid. Not to mentioned actually withdrawing and depositing has severe lag on each item.

I really like the categories, but there is something wrong and/or very inefficient about how this addon works. I wish I knew how to code well so I could fix this myself, but unfortunately I will be stuck with the vanilla mess of a long scrolling list; but at least it has good performance.

Post your current rule code here and I will take a look

I don't know how to do that, if it's possible and not overly cumbersome.

As long as what it does is documented in the wiki, I don't think the function name need be confusing. As I discovered, returning the actual or even effective character CP value has no use at all for any category matching, period, so why not massage what's returned to suit the purpose, as long as it's documented? Surely doing so in an LUA function directly is more efficient than in a parsed and exec'd string?

It doesn't occur for me, and I have many dozens of mods installed. I thought it was odd to declare such a showstopper issue without any further detail. I did, however, have the guild bank frame hang/freeze earlier today when I was experimenting with a category rule, and a bunch of LUA error detail was dumped into the chat frame rather than the usual notification. Is it possible to craft a category rule that when parsed and exec'd could crash the game? That would be quite the exploit.

I cannot reproduce this with any of my guilds, can you give me any more information? Anyone else able to confirm or deny this?

It doesn't really make sense to have a "CharCP" function that returns something besides the actual character CP. Why not build the logic into your custom filter rule?

When I asked for the inclusion of the charcp() function, I was guilty of poor conceptualization. You added the function as I drafted it, but it doesn't work as I intended because I screwed up. What it now returns is the actual character's CP, but if that value is higher than 160 then it becomes useless in tests against gear levels and instead results in erroneous matches. I didn't catch this sooner because I didn't have enough variety of stored gear.

The function needed a test to set a ceiling of 160 on the value that it returns. I have corrected the function locally, but could you add this correction to the next update so that it carries forward?
If there's a more efficient way of coding that by embedding the test directly into the declaration for cp, you're welcome to do it.

Illuminating!

Currently this addon crashes my game when I open the guild bank.