Issue Details (XML | Word | Printable)

Key: CORE-1775
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Vlad Khorsun
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Bad performance of security checking during prepare

Created: 06/Mar/08 08:07 AM   Updated: 18/Nov/08 01:02 PM
Component/s: Engine
Affects Version/s: 2.0.0, 2.0.1, 2.1 Alpha 1, 2.1 Beta 1, 2.0.2, 2.0.3, 2.1 Beta 2, 2.1 RC1
Fix Version/s: 2.0.4, 2.5 Alpha 1

Time Tracking:
Issue & Sub-Tasks
Issue Only
Not Specified

Target: 2.0.4, 2.5 Alpha 1 and 2.1.1
Planning Status: Considered for inclusion

Sub-Tasks  All   Open   

 Description  « Hide
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


 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 08/Mar/08 09:58 AM
Fix is committed into HEAD (2.5 alpha) and 2.0.4. As for 2.1 RC2 it seems it is too late, sorry. I'll add sub-task to commit fix into 2.1.1 or 2.1 RC3