In 192 it's important to have service registered since
https://github.com/JetBrains/intellij-community/commit/f204718c885034bc2fa4be4b281ff4bbd5fa4ef4
Caused by: java.lang.IllegalArgumentException: Argument for @NotNull parameter 'value' of com/intellij/openapi/util/UserDataHolderBase.putUserDataIfAbsent must not be null
at com.intellij.openapi.util.UserDataHolderBase.$$$reportNull$$$0(UserDataHolderBase.java)
at com.intellij.openapi.util.UserDataHolderBase.putUserDataIfAbsent(UserDataHolderBase.java)
at com.intellij.openapi.util.NotNullLazyKey.getValue(NotNullLazyKey.java:41)
at com.intellij.lang.injection.InjectedLanguageManager.getInstance(InjectedLanguageManager.java:41)
at com.intellij.psi.impl.PsiCachedValue.isVeryPhysical(PsiCachedValue.java:74)
at com.intellij.psi.impl.PsiCachedValue.anyChangeImpliesPsiCounterChange(PsiCachedValue.java:57)
Reproduced with Fir2IrTextTestGenerated
Broken in f1e3e26e6cd6e38b473ffe1a23b19b68ebb2d11f.
----
> Task :kotlin-reflect:signArchives FAILED
Build time for tasks:
Compiling kotlin: 1.44s (12.33% of total time)
Processing jars: 4.28s (36.75% of total time)
Uncategorized: 5.39s (46.26% of total time)
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':kotlin-reflect:signArchives'.
> Duplicate key Signature kotlin-reflect:jar.asc:asc:
---
#KT-32192 Fixed
Before this commit, implicit Unit type for function with body and
without type, implicit Boolean type for conditions etc. were 'implicit'
types and resolved types together.
Sometimes this could lead to hard-to-find issues in FIR resolve, because
'implicit' types are usually handled there as 'necessary to resolve'
which is wrong for such effectively-resolved types.
Profiling the compilation of kotlinx.serialization, MaxStackFrameSizeAndLocalsCalculator
causes ~7% of the runtime to be spent in java.lang.Object.hashCode
This is through two uses:
- visitMaxs(..) has a pushed hashSet that causes ~2%
- labelWrappersMap used to attach additional data to asm Labels, causes ~ 5%
visitMaxs can use the existing SmartSet (not to be confused with SmartHashSet)
Analysis of the visitMaxs HashSet creation & sizes:
| What | Amount |
| calls to visitMaxs | 4416 |
| max pushed | 158 |
| median pushed | 4 |
| average pushed | 5.20 |
| stddev pushed | 7.66 |
| 90 percentile | 10 |
Analysis of labelWrappersMap creation & sizes:
| What | Amount |
| ------------------ | ------ |
| hashtables created | 4006 |
| max entries | 175 |
| median entries | 5 |
| average entries | 6.10 |
| stdev entries | 8.28 |
| 90 percentile | 11 |
testing with a non hash based map using an array for keys and an array for values
showed that the cost of MaxStackFrameSizeAndLocalsCalculator became neglible to
the overall running time.
SmartIdentityTable is a Map like structure that uses reference identity for keys.
It uses 2 arrays to store keys & values until the number of entries stored is larger than 10.
At that point it switches to using an IdentityHashMap.
This structure can be used instead of HashMap when reference identity can be used and
the number of entries inserted is small (<= 10) on average, drastically reducing the overhead
of calls to Object.hashCode
Between the two changes, compilation of kotlinx.serialization through kotlinc
commandline decreased from 14 seconds to 11 seconds on my machine
Alexander Gorshenev