Roman Elizarov e26a3ad033 Speed up stdlib readLine function (#3185)
There are several performance optimizations:

* ByteBuffer/CharBuffer/StringBuilder objects pre-allocated and are
  reused on each call to readLine.
* The state for readLine is lazily allocated via JVM classloading
  (using a singleton object).
* There is an auto-detection heuristic for "directEOL" encodings which
  represent LF ('\n') directly as the corresponding byte
  (UTF-8 and many single-byte encodings are like that).
  When "directEOL" encoding is used, then bytes are batched into
  ByteBuffer for a single call to CharsetDecoder.decode which
  results in higher throughput. Otherwise (UTF-16, etc), slower
  byte-by-byte approach is used.
* Bytes and chars are directly moved in/out of byte/char arrays and
  ByteBuffer/CharBuffer wrappers are used only to interface with
  JVM CharsetDecoder class (which is the slowest piece).
* StringBuilder is not used at all for short lines (<=32 chars).

There are also some function improvements to readLine functionality:

* Restriction on "max chars per byte" is lifted, so readLine works with
  all encodings that JVM supports.
* It support on-the-fly changes to system default charset, because
  it rechecks current charset on each call and updates it decoder
  when needed.

All the other features of readLine function are retained:

* It does not read more bytes from System.in than needed, so it
  is compatible with other ways to read System.in. On-the-fly
  changes to System.in are supported.
* It is thread-safe. Its internal mutable state is protected by
  synchronization.
* There is an internal method for tests that supports explicit
  charset specification, but the name of this method has changed.

There are additional tests:

* Check all supported encodings on JVM to make sure that readLine
  works correctly with them all.
* Check unicode code points of different bits length with all standard
  unicode encodings (UTF-8, UTF-16, and UTF-32 in LE/HE byte orders).

Benchmarks that compare different implementations of readLine,
including this one (readLine6NoLV in the set) can be found here:
https://github.com/elizarov/ReadLineBenchmark

Taking BufferedReader as 100% baseline we see that:

* Current readLine is 7.5 times slower than BufferedReader baseline.
* New implementation in this commit is 2.5 timer slower than baseline.
  It is ~3 times faster than existing implementation of readLine.

Altogether these optimizations are enough to enable reading of
~500K lines in sports programming setting under 2s time-limit with
plenty of headroom in time. Example that is using this version of
readLine can be found here:
https://codeforces.com/contest/1322/submission/73005366

#KT-37416 Fixed
2020-03-23 14:36:55 +03:00
2019-08-21 20:20:08 +02:00
2020-01-29 15:01:23 +03:00
2020-03-05 14:01:13 +01:00
2020-02-11 20:27:59 +03:00
2020-02-06 21:03:41 +03:00
2020-03-23 13:50:16 +03:00
2019-11-27 21:26:33 +03:00
2019-10-28 17:21:23 +03:00
2019-11-21 18:36:01 +03:00

official project TeamCity (simple build status) Maven Central GitHub license

Kotlin Programming Language

Welcome to Kotlin! Some handy links:

Editing Kotlin

Build environment requirements

In order to build Kotlin distribution you need to have:

  • JDK 1.6, 1.7, 1.8 and 9

  • Setup environment variables as following:

      JAVA_HOME="path to JDK 1.8"
      JDK_16="path to JDK 1.6"
      JDK_17="path to JDK 1.7"
      JDK_18="path to JDK 1.8"
      JDK_9="path to JDK 9"
    

For local development, if you're not working on bytecode generation or the standard library, it's OK to have only JDK 1.8 and JDK 9 installed, and to point JDK_16 and JDK_17 environment variables to your JDK 1.8 installation.

You also can use Gradle properties to setup JDK_* variables.

Note: The JDK 6 for MacOS is not available on Oracle's site. You can download it here.

On Windows you might need to add long paths setting to the repo:

git config core.longpaths true 

Building

The project is built with Gradle. Run Gradle to build the project and to run the tests using the following command on Unix/macOS:

./gradlew <tasks-and-options>

or the following command on Windows:

gradlew <tasks-and-options>

On the first project configuration gradle will download and setup the dependencies on

  • intellij-core is a part of command line compiler and contains only necessary APIs.
  • idea-full is a full blown IntelliJ IDEA Community Edition to be used in the plugin module.

These dependencies are quite large, so depending on the quality of your internet connection you might face timeouts getting them. In this case you can increase timeout by specifying the following command line parameters on the first run:

./gradlew -Dhttp.socketTimeout=60000 -Dhttp.connectionTimeout=60000

Important gradle tasks

  • clean - clean build results
  • dist - assembles the compiler distribution into dist/kotlinc/ folder
  • ideaPlugin - assembles the Kotlin IDEA plugin distribution into dist/artifacts/Kotlin folder
  • install - build and install all public artifacts into local maven repository
  • runIde - build IDEA plugin and run IDEA with it
  • coreLibsTest - build and run stdlib, reflect and kotlin-test tests
  • gradlePluginTest - build and run gradle plugin tests
  • compilerTest - build and run all compiler tests
  • ideaPluginTest - build and run all IDEA plugin tests

OPTIONAL: Some artifacts, mainly Maven plugin ones, are built separately with Maven. Refer to libraries/ReadMe.md for details.

Building for different versions of IntelliJ IDEA and Android Studio

Kotlin plugin is intended to work with several recent versions of IntelliJ IDEA and Android Studio. Each platform is allowed to have a different set of features and might provide a slightly different API. Instead of using several parallel Git branches, project stores everything in a single branch, but files may have counterparts with version extensions (*.as32, *.172, *.181). The primary file is expected to be replaced with its counterpart when targeting non-default platform.

More detailed description of this scheme can be found at https://github.com/JetBrains/bunches/blob/master/ReadMe.md.

Usually, there's no need to care about multiple platforms as all features are enabled everywhere by default. Additional counterparts should be created if there's an expected difference in behavior or an incompatible API usage is required and there's no reasonable workaround to save source compatibility. Kotlin plugin contains a pre-commit check that shows a warning if a file has been updated without its counterparts.

Development for some particular platform is possible after 'switching' that can be done with Bunch Tool from the command line.

cd kotlin-project-dir

# switching to IntelliJ Idea 2019.1
bunch switch 191

Working with the project in IntelliJ IDEA

Working with the Kotlin project requires at least IntelliJ IDEA 2019.1. You can download IntelliJ IDEA 2019.1 here.

After cloning the project, to import the project in Intellij choose the project directory in the Open project dialog. Then, after project opened, Select File -> New... -> Module from Existing Sources in the menu, and select build.gradle.kts file in the project's root folder.

In the import dialog, select use default gradle wrapper.

To be able to run tests from IntelliJ easily, check Delegate IDE build/run actions to Gradle and choose Gradle Test Runner in the Gradle runner settings after importing the project.

At this time, you can use the latest released 1.3.x version of the Kotlin plugin for working with the code. To make sure you have the latest version installed, use Tools | Kotlin | Configure Kotlin Plugin Updates and press "Check for updates now".

Compiling and running

From this root project there are Run/Debug Configurations for running IDEA or the Compiler Tests for example; so if you want to try out the latest and greatest IDEA plugin

  • VCS -> Git -> Pull
  • Run the "IDEA" run configuration in the project
  • a child IntelliJ IDEA with the Kotlin plugin will then startup

Including into composite build

To include kotlin compiler into composite build you need to define dependencySubstitution for kotlin-compiler module in settings.gradle

includeBuild('/path/to/kotlin') {
    dependencySubstitution {
        substitute module('org.jetbrains.kotlin:kotlin-compiler') with project(':include:kotlin-compiler')
    }
}

License

Kotlin is distributed under the terms of the Apache License (Version 2.0). See license folder for details.

Contributing

Please be sure to review Kotlin's contributing guidelines to learn how to help the project.

S
Description
The Kotlin Programming Language.
Readme 2.1 GiB
Languages
Kotlin 79.9%
Java 10.4%
Swift 4.3%
C 2.8%
C++ 2.1%
Other 0.3%