Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-108

Fix performance regression in LUBM Q9 introduced by INT64 change set

    Details

    • Type: Task
    • Status: Done
    • Resolution: Done
    • Affects Version/s: QUADS_QUERY_BRANCH
    • Fix Version/s: None
    • Component/s: B+Tree

      Description

      LUBM Q9 has regressed in performance. It is currently taking ~ 6 seconds to evaluate. Historically, this query should take ~ 3 seconds to evaluate. Change sets which might be responsible include the INT64_BRANCH, various work on the RWStore, etc.

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        I have tracked down this regression to the merge in of the changes from the INT64 branch. I suspect that this has to do with how we are encoding the range counts in the B+Tree nodes and leaves, as that was the primary change in the INT64 branch. It is interesting that the performance regression is only experienced for Q2 and Q9, but those are the two most complex queries.

        In order to address this performance regression, we will need to examine the coding for the range count data in the nodes and leaves both in the code and under a profiler using suitable stress tests and benchmarks. Note that the same coding is currently being used for the version timestamps.

        r4476: This is the quads branch prior to lex joins and int64 change sets.
             [java] Load: 6890949 stmts added in 153.663 secs, rate= 44843, commitLatency=0ms
             [java] Closure: ClosureStats{mutationCount=1699274, elapsed=88966ms, rate=19100}
             [java] Wrote: 739377152 bytes.
             [java] Total elapsed=247810ms
        
        r4476 query performance against its own data load.
             [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ###
             [java] BIGDATA_SPARQL_ENDPOINT	#trials=10	#parallel=1
             [java] query	Time	Result#
             [java] query1	104	4
             [java] query3	46	6
             [java] query4	122	34
             [java] query5	82	719
             [java] query7	38	61
             [java] query8	256	6463
             [java] query10	36	0
             [java] query11	38	0
             [java] query12	39	0
             [java] query13	36	0
             [java] query14	2701	393730
             [java] query6	3118	430114
             [java] query2	580	130
             [java] query9	2780	8627
             [java] Total	9976
        
        r4523 (int64) query performance against: r4476 data load
             [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ###
             [java] BIGDATA_SPARQL_ENDPOINT	#trials=10	#parallel=1
             [java] query	Time	Result#
             [java] query1	85	4
             [java] query3	46	6
             [java] query4	100	34
             [java] query5	82	719
             [java] query7	31	61
             [java] query8	268	6463
             [java] query10	35	0
             [java] query11	36	0
             [java] query12	39	0
             [java] query13	37	0
             [java] query14	2715	393730
             [java] query6	2964	430114
             [java] query2	625	130
             [java] query9	3020	8627
             [java] Total	10083
        
        r4529 (lex joins) query performance r4476 data load
             [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ###
             [java] BIGDATA_SPARQL_ENDPOINT	#trials=10	#parallel=1
             [java] query	Time	Result#
             [java] query1	104	4
             [java] query3	53	6
             [java] query4	101	34
             [java] query5	82	719
             [java] query7	34	61
             [java] query8	261	6463
             [java] query10	37	0
             [java] query11	39	0
             [java] query12	40	0
             [java] query13	38	0
             [java] query14	2701	393730
             [java] query6	2946	430114
             [java] query2	624	130
             [java] query9	3085	8627
             [java] Total	10145
        
        r4523: new database load (this is with the merge from the int64 branch)
             [java] Load: 6890949 stmts added in 152.594 secs, rate= 45158, commitLatency=0ms
             [java] Closure: ClosureStats{mutationCount=1699274, elapsed=92888ms, rate=18293}
             [java] Wrote: 730464256 bytes.
             [java] Total elapsed=250294ms
        
        r4523 query performance against its own data load
             [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ###
             [java] BIGDATA_SPARQL_ENDPOINT	#trials=10	#parallel=1
             [java] query	Time	Result#
             [java] query1	94	4
             [java] query3	46	6
             [java] query4	126	34
             [java] query5	97	719
             [java] query7	27	61
             [java] query8	332	6463
             [java] query10	34	0
             [java] query11	35	0
             [java] query12	38	0
             [java] query13	38	0
             [java] query14	2699	393730
             [java] query6	2673	430114
             [java] query2	1172	130               REGRESSION
             [java] query9	6290	8627              REGRESSION
             [java] Total	13701
        
        r4529 (lex joins) query performance against r4523 data load.
             [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ###
             [java] BIGDATA_SPARQL_ENDPOINT	#trials=10	#parallel=1
             [java] query	Time	Result#
             [java] query1	87	4
             [java] query3	47	6
             [java] query4	100	34
             [java] query5	84	719
             [java] query7	50	61
             [java] query8	337	6463
             [java] query10	39	0
             [java] query11	41	0
             [java] query12	42	0
             [java] query13	36	0
             [java] query14	2677	393730
             [java] query6	2918	430114
             [java] query2	1193	130               REGRESSION
             [java] query9	6255	8627              REGRESSION
             [java] Total	13906
        
        Show
        bryanthompson bryanthompson added a comment - I have tracked down this regression to the merge in of the changes from the INT64 branch. I suspect that this has to do with how we are encoding the range counts in the B+Tree nodes and leaves, as that was the primary change in the INT64 branch. It is interesting that the performance regression is only experienced for Q2 and Q9, but those are the two most complex queries. In order to address this performance regression, we will need to examine the coding for the range count data in the nodes and leaves both in the code and under a profiler using suitable stress tests and benchmarks. Note that the same coding is currently being used for the version timestamps. r4476: This is the quads branch prior to lex joins and int64 change sets. [java] Load: 6890949 stmts added in 153.663 secs, rate= 44843, commitLatency=0ms [java] Closure: ClosureStats{mutationCount=1699274, elapsed=88966ms, rate=19100} [java] Wrote: 739377152 bytes. [java] Total elapsed=247810ms r4476 query performance against its own data load. [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ### [java] BIGDATA_SPARQL_ENDPOINT #trials=10 #parallel=1 [java] query Time Result# [java] query1 104 4 [java] query3 46 6 [java] query4 122 34 [java] query5 82 719 [java] query7 38 61 [java] query8 256 6463 [java] query10 36 0 [java] query11 38 0 [java] query12 39 0 [java] query13 36 0 [java] query14 2701 393730 [java] query6 3118 430114 [java] query2 580 130 [java] query9 2780 8627 [java] Total 9976 r4523 (int64) query performance against: r4476 data load [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ### [java] BIGDATA_SPARQL_ENDPOINT #trials=10 #parallel=1 [java] query Time Result# [java] query1 85 4 [java] query3 46 6 [java] query4 100 34 [java] query5 82 719 [java] query7 31 61 [java] query8 268 6463 [java] query10 35 0 [java] query11 36 0 [java] query12 39 0 [java] query13 37 0 [java] query14 2715 393730 [java] query6 2964 430114 [java] query2 625 130 [java] query9 3020 8627 [java] Total 10083 r4529 (lex joins) query performance r4476 data load [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ### [java] BIGDATA_SPARQL_ENDPOINT #trials=10 #parallel=1 [java] query Time Result# [java] query1 104 4 [java] query3 53 6 [java] query4 101 34 [java] query5 82 719 [java] query7 34 61 [java] query8 261 6463 [java] query10 37 0 [java] query11 39 0 [java] query12 40 0 [java] query13 38 0 [java] query14 2701 393730 [java] query6 2946 430114 [java] query2 624 130 [java] query9 3085 8627 [java] Total 10145 r4523: new database load (this is with the merge from the int64 branch) [java] Load: 6890949 stmts added in 152.594 secs, rate= 45158, commitLatency=0ms [java] Closure: ClosureStats{mutationCount=1699274, elapsed=92888ms, rate=18293} [java] Wrote: 730464256 bytes. [java] Total elapsed=250294ms r4523 query performance against its own data load [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ### [java] BIGDATA_SPARQL_ENDPOINT #trials=10 #parallel=1 [java] query Time Result# [java] query1 94 4 [java] query3 46 6 [java] query4 126 34 [java] query5 97 719 [java] query7 27 61 [java] query8 332 6463 [java] query10 34 0 [java] query11 35 0 [java] query12 38 0 [java] query13 38 0 [java] query14 2699 393730 [java] query6 2673 430114 [java] query2 1172 130 REGRESSION [java] query9 6290 8627 REGRESSION [java] Total 13701 r4529 (lex joins) query performance against r4523 data load. [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ### [java] BIGDATA_SPARQL_ENDPOINT #trials=10 #parallel=1 [java] query Time Result# [java] query1 87 4 [java] query3 47 6 [java] query4 100 34 [java] query5 84 719 [java] query7 50 61 [java] query8 337 6463 [java] query10 39 0 [java] query11 41 0 [java] query12 42 0 [java] query13 36 0 [java] query14 2677 393730 [java] query6 2918 430114 [java] query2 1193 130 REGRESSION [java] query9 6255 8627 REGRESSION [java] Total 13906
        Hide
        bryanthompson bryanthompson added a comment -

        Note: This performance regression is only apparent when you run against a journal built with a bigdata r4523+. If you are running against a journal built from a prior bigdata SVN version then there are int32 counters in the database and no performance regression is observed.

        Show
        bryanthompson bryanthompson added a comment - Note: This performance regression is only apparent when you run against a journal built with a bigdata r4523+. If you are running against a journal built from a prior bigdata SVN version then there are int32 counters in the database and no performance regression is observed.
        Hide
        bryanthompson bryanthompson added a comment -

        We have run into this sort of problem before and that this is what led to the FastRDFValueCoder2 class. Wrapping the byte[] with an InputBitStream to extract exactly the necessary bits is MUCH slower than the nibble based indexing that we do in FastRDFValueCoder2. Since the spanned tuple counts tend to be very close from child to child, we should use a similar strategy in which we find the minimum #of nibbles (or bytes) for coding the maximum difference across the children and then use a fixed width nibble[] or byte[] for the range count data. In this case, I think that using bytes rather than nibbles would be the better choice since the code will be significantly simpler. The same change should also be applied to the version timestamps which are stored using the same delta coding scheme as the spanned tuple counts. The version number for the coded nodes must be bumped when we make the change to how we code the #of spanned tuples. Likewise, the version number for both nodes and leaves needs to be bumped when changing the coding of the version timestamp metadata.

        Show
        bryanthompson bryanthompson added a comment - We have run into this sort of problem before and that this is what led to the FastRDFValueCoder2 class. Wrapping the byte[] with an InputBitStream to extract exactly the necessary bits is MUCH slower than the nibble based indexing that we do in FastRDFValueCoder2. Since the spanned tuple counts tend to be very close from child to child, we should use a similar strategy in which we find the minimum #of nibbles (or bytes) for coding the maximum difference across the children and then use a fixed width nibble[] or byte[] for the range count data. In this case, I think that using bytes rather than nibbles would be the better choice since the code will be significantly simpler. The same change should also be applied to the version timestamps which are stored using the same delta coding scheme as the spanned tuple counts. The version number for the coded nodes must be bumped when we make the change to how we code the #of spanned tuples. Likewise, the version number for both nodes and leaves needs to be bumped when changing the coding of the version timestamp metadata.
        Hide
        bryanthompson bryanthompson added a comment -

        Another possibility is to adapt the following method to return permit the extraction of up to a 64-bit integer.

        int BytesUtil#getBits(final byte[] a, final int off, final int len)
        

        This method was developed for the HTree and extracts up to an int32 value from the specified bit offset. The problem with InputBitStream is that it is optimized for operations on a (repositionable) stream. However, since it is stateful, it is not possible to wrap the node/leaf data record once and then use the InputBitStream to decode bits at random locations. However, BytesUtil#getBits() method has low overhead when you need to extract bits using a random access pattern.

        This solution could be tested against existing data to prove the concept. If the performance is satisfactory, then we would need to develop a version of getBits() which was capable of extracting an int64 value, not just an int32 value. This path potentially offers the best of both worlds
        - the tightest delta coding and fast random access.

        Show
        bryanthompson bryanthompson added a comment - Another possibility is to adapt the following method to return permit the extraction of up to a 64-bit integer. int BytesUtil#getBits(final byte[] a, final int off, final int len) This method was developed for the HTree and extracts up to an int32 value from the specified bit offset. The problem with InputBitStream is that it is optimized for operations on a (repositionable) stream. However, since it is stateful, it is not possible to wrap the node/leaf data record once and then use the InputBitStream to decode bits at random locations. However, BytesUtil#getBits() method has low overhead when you need to extract bits using a random access pattern. This solution could be tested against existing data to prove the concept. If the performance is satisfactory, then we would need to develop a version of getBits() which was capable of extracting an int64 value, not just an int32 value. This path potentially offers the best of both worlds - the tightest delta coding and fast random access.
        Hide
        bryanthompson bryanthompson added a comment -

        I've asked Martyn to look at whether BytesUtil#getBits(byte[],off,len) (or a similar method) could be aligned with the DSI InputBitStream and provide fast stateless random access to slices of up to 64-bits for this purpose.

        If this approach pans out, then it is trivial to modify the DefaultNodeCoder (and DefaultLeafCoder) to use the stateless getBits() style method for random access.

        Show
        bryanthompson bryanthompson added a comment - I've asked Martyn to look at whether BytesUtil#getBits(byte[],off,len) (or a similar method) could be aligned with the DSI InputBitStream and provide fast stateless random access to slices of up to 64-bits for this purpose. If this approach pans out, then it is trivial to modify the DefaultNodeCoder (and DefaultLeafCoder) to use the stateless getBits() style method for random access.
        Hide
        bryanthompson bryanthompson added a comment -

        We have demonstrated to our satisfaction that the performance issue can in fact be resolved using BytesUtil#getBits() and an int64 version (BytesUtil#getBits64()). We are now looking into any further performance optimizations which might be made in this area.

        r4577 with getBits() if nbits LTE32: This captures most of the lost performance.

        1st trial
        
             [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ###
             [java] BIGDATA_SPARQL_ENDPOINT     #trials=10      #parallel=1
             [java] query       Time    Result#
             [java] query1      131     4
             [java] query3      62      6
             [java] query4      135     34
             [java] query5      83      719
             [java] query7      38      61
             [java] query8      307     6463
             [java] query10     37      0
             [java] query11     41      0
             [java] query12     36      0
             [java] query13     34      0
             [java] query14     2942    393730
             [java] query6      3437    430114
             [java] query2      873     130
             [java] query9      4490    8627
             [java] Total       12646
        
        2nd trial
             [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ###
             [java] BIGDATA_SPARQL_ENDPOINT	#trials=10	#parallel=1
             [java] query	Time	Result#
             [java] query1	39	4
             [java] query3	33	6
             [java] query4	57	34
             [java] query5	49	719
             [java] query7	34	61
             [java] query8	180	6463
             [java] query10	35	0
             [java] query11	37	0
             [java] query12	38	0
             [java] query13	44	0
             [java] query14	2704	393730
             [java] query6	2809	430114
             [java] query2	674	130
             [java] query9	4255	8627
             [java] Total	10988
        
        same code version, but further modified to factor out minChildEntryCount so that we extract it exactly once.
        
        1st trial
             [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ###
             [java] BIGDATA_SPARQL_ENDPOINT	#trials=10	#parallel=1
             [java] query	Time	Result#
             [java] query1	84	4
             [java] query3	39	6
             [java] query4	112	34
             [java] query5	84	719
             [java] query7	41	61
             [java] query8	269	6463
             [java] query10	37	0
             [java] query11	40	0
             [java] query12	41	0
             [java] query13	35	0
             [java] query14	2845	393730
             [java] query6	3012	430114
             [java] query2	722	130
             [java] query9	3772	8627
             [java] Total	11133
        
        2nd trial
             [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ###
             [java] BIGDATA_SPARQL_ENDPOINT	#trials=10	#parallel=1
             [java] query	Time	Result#
             [java] query1	43	4
             [java] query3	33	6
             [java] query4	54	34
             [java] query5	51	719
             [java] query7	33	61
             [java] query8	177	6463
             [java] query10	34	0
             [java] query11	37	0
             [java] query12	39	0
             [java] query13	38	0
             [java] query14	2610	393730
             [java] query6	2895	430114
             [java] query2	608	130
             [java] query9	3749	8627
             [java] Total	10401
        
        Show
        bryanthompson bryanthompson added a comment - We have demonstrated to our satisfaction that the performance issue can in fact be resolved using BytesUtil#getBits() and an int64 version (BytesUtil#getBits64()). We are now looking into any further performance optimizations which might be made in this area. r4577 with getBits() if nbits LTE32: This captures most of the lost performance. 1st trial [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ### [java] BIGDATA_SPARQL_ENDPOINT #trials=10 #parallel=1 [java] query Time Result# [java] query1 131 4 [java] query3 62 6 [java] query4 135 34 [java] query5 83 719 [java] query7 38 61 [java] query8 307 6463 [java] query10 37 0 [java] query11 41 0 [java] query12 36 0 [java] query13 34 0 [java] query14 2942 393730 [java] query6 3437 430114 [java] query2 873 130 [java] query9 4490 8627 [java] Total 12646 2nd trial [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ### [java] BIGDATA_SPARQL_ENDPOINT #trials=10 #parallel=1 [java] query Time Result# [java] query1 39 4 [java] query3 33 6 [java] query4 57 34 [java] query5 49 719 [java] query7 34 61 [java] query8 180 6463 [java] query10 35 0 [java] query11 37 0 [java] query12 38 0 [java] query13 44 0 [java] query14 2704 393730 [java] query6 2809 430114 [java] query2 674 130 [java] query9 4255 8627 [java] Total 10988 same code version, but further modified to factor out minChildEntryCount so that we extract it exactly once. 1st trial [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ### [java] BIGDATA_SPARQL_ENDPOINT #trials=10 #parallel=1 [java] query Time Result# [java] query1 84 4 [java] query3 39 6 [java] query4 112 34 [java] query5 84 719 [java] query7 41 61 [java] query8 269 6463 [java] query10 37 0 [java] query11 40 0 [java] query12 41 0 [java] query13 35 0 [java] query14 2845 393730 [java] query6 3012 430114 [java] query2 722 130 [java] query9 3772 8627 [java] Total 11133 2nd trial [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ### [java] BIGDATA_SPARQL_ENDPOINT #trials=10 #parallel=1 [java] query Time Result# [java] query1 43 4 [java] query3 33 6 [java] query4 54 34 [java] query5 51 719 [java] query7 33 61 [java] query8 177 6463 [java] query10 34 0 [java] query11 37 0 [java] query12 39 0 [java] query13 38 0 [java] query14 2610 393730 [java] query6 2895 430114 [java] query2 608 130 [java] query9 3749 8627 [java] Total 10401
        Hide
        bryanthompson bryanthompson added a comment -

        Same code revision, but without synchronized(childRefs) in Node#_getChild(int). You can see that this shaves off a little more time on the LUBM Q2 and Q9 queries.

        1st trial:
            [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ###
             [java] BIGDATA_SPARQL_ENDPOINT	#trials=10	#parallel=1
             [java] query	Time	Result#
             [java] query1	96	4
             [java] query3	47	6
             [java] query4	134	34
             [java] query5	84	719
             [java] query7	28	61
             [java] query8	285	6463
             [java] query10	38	0
             [java] query11	39	0
             [java] query12	42	0
             [java] query13	38	0
             [java] query14	2620	393730
             [java] query6	3072	430114
             [java] query2	700	130
             [java] query9	3744	8627
             [java] Total	10967
        
        2nd trial
             [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ###
             [java] BIGDATA_SPARQL_ENDPOINT	#trials=10	#parallel=1
             [java] query	Time	Result#
             [java] query1	39	4
             [java] query3	29	6
             [java] query4	46	34
             [java] query5	45	719
             [java] query7	32	61
             [java] query8	178	6463
             [java] query10	36	0
             [java] query11	38	0
             [java] query12	37	0
             [java] query13	36	0
             [java] query14	2619	393730
             [java] query6	2780	430114
             [java] query2	597	130
             [java] query9	3670	8627
             [java] Total	10182
        
        Show
        bryanthompson bryanthompson added a comment - Same code revision, but without synchronized(childRefs) in Node#_getChild(int). You can see that this shaves off a little more time on the LUBM Q2 and Q9 queries. 1st trial: [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ### [java] BIGDATA_SPARQL_ENDPOINT #trials=10 #parallel=1 [java] query Time Result# [java] query1 96 4 [java] query3 47 6 [java] query4 134 34 [java] query5 84 719 [java] query7 28 61 [java] query8 285 6463 [java] query10 38 0 [java] query11 39 0 [java] query12 42 0 [java] query13 38 0 [java] query14 2620 393730 [java] query6 3072 430114 [java] query2 700 130 [java] query9 3744 8627 [java] Total 10967 2nd trial [java] ### Finished testing BIGDATA_SPARQL_ENDPOINT ### [java] BIGDATA_SPARQL_ENDPOINT #trials=10 #parallel=1 [java] query Time Result# [java] query1 39 4 [java] query3 29 6 [java] query4 46 34 [java] query5 45 719 [java] query7 32 61 [java] query8 178 6463 [java] query10 36 0 [java] query11 38 0 [java] query12 37 0 [java] query13 36 0 [java] query14 2619 393730 [java] query6 2780 430114 [java] query2 597 130 [java] query9 3670 8627 [java] Total 10182
        Hide
        bryanthompson bryanthompson added a comment -

        The following changes were made to support resolution of this issue:


        - BytesUtil#getBits()
        - bug fixes by Martyn for some edge cases.
        - BytesUtil#getBits64()
        - implemented by Martyn.
        - DefaultNodeCoder
        - modified to use getBits64() rather than InputBitStream for fast random access to the #of tuples per child node. also modified to cache the minimum #of tuples spanned per child across the children to shave off some additional cycles.
        - DefaultLeafCoder
        - modified exactly per DefaultNodeCoder to provide the same optimizations when version timestamps are in use (e.g., when the indices support transactional isolation).

        The changes listed above all focus on the INT64_BRANCH performance regression. In addition, the following change was made to remove a potential synchronization hot spot during concurrent query:


        - Node#_getChild(int)
        - modified to remove the use of the synchronized(childRefs) construct. Proper synchronization should be provided by the Memoizer pattern for read-only B+Tree views and by the single-threaded for mutation contract in combination with the UnisolatedReadWriteIndex class for mutable B+Tree views.

        Martyn is continuing to look into performance optimizations within getBits().

        We will have a CI data point on this in ~ 2 hours.

        Committed revision r4581.

        Show
        bryanthompson bryanthompson added a comment - The following changes were made to support resolution of this issue: - BytesUtil#getBits() - bug fixes by Martyn for some edge cases. - BytesUtil#getBits64() - implemented by Martyn. - DefaultNodeCoder - modified to use getBits64() rather than InputBitStream for fast random access to the #of tuples per child node. also modified to cache the minimum #of tuples spanned per child across the children to shave off some additional cycles. - DefaultLeafCoder - modified exactly per DefaultNodeCoder to provide the same optimizations when version timestamps are in use (e.g., when the indices support transactional isolation). The changes listed above all focus on the INT64_BRANCH performance regression. In addition, the following change was made to remove a potential synchronization hot spot during concurrent query: - Node#_getChild(int) - modified to remove the use of the synchronized(childRefs) construct. Proper synchronization should be provided by the Memoizer pattern for read-only B+Tree views and by the single-threaded for mutation contract in combination with the UnisolatedReadWriteIndex class for mutable B+Tree views. Martyn is continuing to look into performance optimizations within getBits(). We will have a CI data point on this in ~ 2 hours. Committed revision r4581.
        Hide
        bryanthompson bryanthompson added a comment -

        CI is clean. LUBM performance has been restored. BSBM performance is at least 33k QMpH (using the reduced query mix, e.g., w/o Q5). Martyn is continuing to look at getBits() optimizations, but I am going to close this issue as we have recovered query performance.

        Show
        bryanthompson bryanthompson added a comment - CI is clean. LUBM performance has been restored. BSBM performance is at least 33k QMpH (using the reduced query mix, e.g., w/o Q5). Martyn is continuing to look at getBits() optimizations, but I am going to close this issue as we have recovered query performance.

          People

          • Assignee:
            martyncutcher martyncutcher
            Reporter:
            bryanthompson bryanthompson
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: