Fwd: confirm subscribe to java-user@lucene.apache.org

[manoj raj <ma...@gmail.com>]

Dear sir/madam,

I have been working with lucene 3.0.3 and wish to upgrade to lucene 4.3 but
i found the performance of 4.3. slower than 3.0.3.  I have attached the
code used to test and results of test along with this mail. Is there any
specific usage pattern to be followed to improve the performance of 4.3


LUCENE 3.0.3 PERFORMANCE

NO OF RECORDS
NO OF FIELDS
INDEX TIME
(IN MS)
SEARCH TIME 1
(IN MS)
SEARCH TIME 2
(IN MS)
SEARCH TIME3
(IN MS)
NO OF FIELDS SEARCHED
SORT FIELDS
INDEX SIZE
1000
3
454
54
1
0
1
NO
66.5KB
10000
3
1117
58
1
2
1
NO 687.7KB
100000
3
2565
71
5
2
1
NO
7.3MB
1000
10
560
64
3
3
3
NO
205.2KB
10000
10
1542
62
3
2
3
NO
2.1MB
100000
10
5018
116
8
9
3
NO
22.7MB
1000
10
601
146
2
2
3
YES
205.2KB
10000
10
1491
72
2
2
3
YES
2.1MB
100000
10
4176
109
7
7
3
YES
22.7MB

LUCENE 4.3 PERFORMANCE
NO OF RECORDS
NO OF FIELDS
INDEX TIME
SEARCH TIME1
(IN MS)
SEARCH TIME2
(IN MS)
SEARCH TIME3
(IN MS)
NO OF FIELDS
SORT FIELDS
INDEX SIZE
1000
3
648
70
1
0
1
NO
44.2KB
10000
3
1811
73
1
1
1
NO
434.5KB
100000
3
2792
81
2
3
1
NO
4.6MB
1000
10
972
73
1
1
3
NO
130.9KB
10000
10
2181
72
2
1
3
NO
1.3MB
100000
10
5104
79
3
4
3
NO
13.5MB
1000
10
1056
101
1
0
3
YES
130.9KB
10000
10
2080
160
1
0
3
YES
1.3MB
100000
10
5301
262
2
1
3
YES
13.4MB


LUCENE 3.0.3 INDEX SEARCHED WITH LUCENE 4.3
NO OF RECORDS
NO OF FIELDS
INDEX TIME
SEARCH TIME1
(IN MS)
SEARCH TIME3
(IN MS)SEARCH TIME3
(IN MS)NO OF FIELDS
SORT FIELDS
INDEX SIZE
1000
3
404
31
1
0
1
NO
66.5KB
10000
3
1115
29
1
1
1
NO
687.7KB
100000
3
2383
35
2
3
1
NO
7.3MB
1000
10
657
28
2
1
3
NO
202.5KB
10000
10
1548
31
3
2
3
NO
2.1MB
100000
10
4335
41
6
5
3
NO
22.7MB
1000
10
579
67
1
1
3
YES
202.5KB
10000
10
1645
162
1
1
3
YES
2.1MB
100000
10
4294
292
4
3
3
YES
22.7MB



Thanks and Regards,
R.Manoj

Re: confirm subscribe to java-user@lucene.apache.org

[Adrien Grand <jp...@gmail.com>]

Hi Manoj,

This is maybe related to the compression support which was added in Lucene
4.1. Although it improves performance on large indexes, it might prove to
be slightly faster on indexes that completely fit in the file-system cache,
especially if you fetch a large number of records at each request.
Compression can be disabled by using a custom codec but I don't recommend
it unless absolutely required.

-- 
Adrien