Bug 564092 - [search]Evaluate move from SimpleLookupTable in DiskIndex/MemoryIndex
Summary: [search]Evaluate move from SimpleLookupTable in DiskIndex/MemoryIndex
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.17   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-08 12:42 EDT by Andrey Loskutov CLA
Modified: 2021-12-07 13:44 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Loskutov CLA 2020-06-08 12:42:43 EDT 
I'm seeing long MemoryIndex run times trying to remove non-existing index entries in a huge Java project where 200.000 files where removed. As result, "System: Java Indexing ..." appears for a long time, *not* blocking the build but heavily loading 4 CPU cores out of 16 on a Xeon with 256 GB RAM.

The time is spent mostly in updating SimpleLookupTable.
The indexer jobs are doing basically only this:

at org.eclipse.jdt.internal.compiler.util.SimpleLookupTable.put(SimpleLookupTable.java:105)
at org.eclipse.jdt.internal.core.index.MemoryIndex.remove(MemoryIndex.java:125)
at org.eclipse.jdt.internal.core.index.Index.remove(Index.java:186)
at org.eclipse.jdt.internal.core.search.indexing.RemoveFromIndex.execute(RemoveFromIndex.java:40)
at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:401)
at java.base/java.lang.Thread.run(Thread.java:834)

I haven't profiled this yet, but I believe that similar to other cases, SimpleLookupTable is "too simple" compared with default HashMap implementation and shouldn't be used anywhere where performance is important.