You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Starting with 2.0 release security checks was slow compared with 1.5.x releases.
I have test case, sent to me privately, where prepare of statement took 15 ms on FB 1.5.4 and more than 90ms on higher versions.
Statement is UPDATE of table with few triggers with complex logic.
The reasons for slowdown is :
a) SCL_get_class search for given security class name within linked list of cached security classes (att_security_classes). This is slow as this list may contain hundreds of entries. Since v2.0 simple call of strcmp() was replaced by overloaded operator ==. Unfortunately it is not expanded inline thus slowdown.
b) Since v2.1 i see fetches from both RDB$RELATIONS and RDB$RELATION_FIELDS during prepare while v1.5.4 and v2.0.3 fetches only RDB$RELATION_FIELDS. I found that CMP\verify_trigger_access calls MET_lookup_field only before v 2.1 and both MET_lookup_field and MET_relation_default_class since v2.1. So far i didn't found reasons why it is so.
Offered solution :
a) in HEAD (v2.5) i'll replace linked list of SecurityClass'es by BePlusTree to allow faster searches.
This make prepare time in my test case again 15ms
b) in 2.0.x and 2.1.x releases i offer to return strcnmp() instead of operator == for string comparison in SCL_get_class
This make prepare time in my test case near 45ms
Submitted by: @hvlad
Jira_subtask_outward CORE1779
Votes: 1
Starting with 2.0 release security checks was slow compared with 1.5.x releases.
I have test case, sent to me privately, where prepare of statement took 15 ms on FB 1.5.4 and more than 90ms on higher versions.
Statement is UPDATE of table with few triggers with complex logic.
The reasons for slowdown is :
a) SCL_get_class search for given security class name within linked list of cached security classes (att_security_classes). This is slow as this list may contain hundreds of entries. Since v2.0 simple call of strcmp() was replaced by overloaded operator ==. Unfortunately it is not expanded inline thus slowdown.
b) Since v2.1 i see fetches from both RDB$RELATIONS and RDB$RELATION_FIELDS during prepare while v1.5.4 and v2.0.3 fetches only RDB$RELATION_FIELDS. I found that CMP\verify_trigger_access calls MET_lookup_field only before v 2.1 and both MET_lookup_field and MET_relation_default_class since v2.1. So far i didn't found reasons why it is so.
Offered solution :
a) in HEAD (v2.5) i'll replace linked list of SecurityClass'es by BePlusTree to allow faster searches.
This make prepare time in my test case again 15ms
b) in 2.0.x and 2.1.x releases i offer to return strcnmp() instead of operator == for string comparison in SCL_get_class
This make prepare time in my test case near 45ms
Commits: f808459 4505e0a 7d54298
The text was updated successfully, but these errors were encountered: