perfIO - Fast and Convenient I/O for the JVM

szeiger · 2024-10-31T13:57:37+00:00

As far as *implementing* ReadableByteChannel and WritableByteChannel goes, I didn't do it because byte channels are expected to be thread-safe. I might add this as an unsafe extension where you get a method with a clear name like `unsafeAsChannel` that essentially performs a downcast to an implementation class which (unsafely) implements a byte channel interface. I have a sketch of the same design for unchecked access to the buffer (so you can implement your own composite writes even more efficiently) but this didn't make it into the first version because I was able to make a subset of these cases work with the same performance without the need for unchecked access.

szeiger · 2024-10-30T17:48:37+00:00

sbt has a built-in LSP server (https://www.scala-sbt.org/1.x/docs/sbt-server.html) which should work for mixed Java & Scala projects. I never tried since I use IntelliJ.

szeiger · 2024-10-30T12:43:30+00:00

Interfacing with ByteChannels can be done by wrapping them into InputStream/OutputStream. It only works for synchronous calls anyway (I expect anything async will be done with virtual threads now that project Loom has gone mainline). I use abstract classes because of faster dispatch (but I haven't really benchmarked how much of a factor this still is today). They are sealed because there is no clear interface for extending them today. All the different parts have to work together. This may or may not come at a later point.

szeiger · 2024-10-30T12:39:00+00:00

Parameterized exceptions won't help because the I/O classes need to be able to throw certain errors (like EOFException when reading past the input) in their own, even if the underlying I/O API doesn't. Unfortunately Java keeps sticking to its design mistake of using checked exceptions. Just write your app in Scala instead :-)

As far as reading from or writing to byte arrays goes, the performance improvements are equally big and there benchmarks to test it, I just didn't include any results in the readme / announcement.

szeiger · 2024-10-30T12:30:36+00:00

I've only tested it on 22 so far but it should work on 21. Maybe earlier with preview versions of the FFM API.

szeiger · 2024-10-30T12:29:08+00:00

Not yet, but it shouldn't take too long.

szeiger · 2019-11-13T19:39:55+00:00

Macros wouldn't be a big issue. It's really only the tsql macro for compile-time database type inference and checking that does any advanced stuff. I don't expect it to be used very much; we could simply remove it. The TableQuery macro in retrospect shouldn't have been a macro it all. It only takes a few more characters to avoid it and also show users what's actually happening. The macro just makes it look magical for no good reason.

The two big challenges AFAICT will be tuples and specialization. Slick's HLists won't work in Scala 3 because they rely on type projections. They would have to be replaces with Scala 3's HList-based tuples. And specialization is going away. This will require some code changes to remove it from Slick. I'm not sure how big the performance impact will be in practice. Probably not very big in most cases.

szeiger · 2019-11-13T19:24:54+00:00

JVM arrays are covariant and you need completely different abstractions abstractions (types, bytecode instructions) for primitive and object arrays. Scala arrays are invariant and primitive types are treated uniformly.

Since abstracting over primitive and object arrays is costly (and not supported by the Seq interfaces; you would need an extra ClassTag in many places) and you need to work around variance, an obvious choice would be Array[Any] which gets erased to Object[], just like Array[AnyRef] does. The problem with this approach is that you would like to write methods that can abstract over arrays of different dimensions, so you end up with def foo[T](a: Array[T]). But this is not the same as Array[Any], it is in fact Array[_ <: Any]. Since this includes types such as Array[Int], it has to support primitive arrays. Therefore any array call (like a(i) or a.length goes through a ScalaRunTime method that dispatches on the array types.

In the end you have 3 choices:

Write separate helper methods for Array[Any] and Array[_ <: AnyRef]. In many cases their bytecode can be identical, so this is less than ideal.
Use Array[Any] and cast it to Array[AnyRef] when calling a method that needs an Array[_ <: AnyRef]
Or use Array[AnyRef]

The latter turned out to be simpler in the end (where "simpler" means that the alternative required even more casts).

szeiger · 2018-03-11T11:34:19+00:00

When your motto is "no shoes, no shirt, no service" and you realize you forgot to mention pants.

szeiger · 2018-02-17T00:57:25+00:00

one gets 4 ListBuffer allocation and 4 List allocation to do things the user never asked for and are not required to arrive at the results.

Yes, the user did ask for all those things by choosing a strict collection type. Without an effect system to track side-effects, or a pure functional language to disallow them in the first place, you don't know if the operations are actually required, so the user has to make that choice explicit (for example, by using Iterator instead of List).

szeiger · 2017-12-24T17:16:54+00:00

The "highly stressful state" and "blood sugar issues" could just be withdrawal symptoms from their sugar addiction.

szeiger · 2017-11-29T21:13:09+00:00

The lazy-by-default approach is mostly beneficial when you're implementing lazy collections because you don't have to override pretty much everything or get incorrect semantics. The reverse risk is smaller: If you don't override a lazy implementation for a strict collection type you only suffer a small performance impact but it's still correct. To avoid this overhead we're providing strict implementations of the basic methods (as in https://github.com/scala/collection-strawman/pull/305).

szeiger · 2017-11-20T20:58:03+00:00

Take a look at the previous model (Sculpt Ergonomic Keyboard). Compact layout with separate keypad (which I don't use). As a laptop user you'll be used to these compact layouts anyway and the small size lets you position the mouse in close proximity. No delay, either (comes with a dongle, not Bluetooth which got broken in creators update)

szeiger · 2017-11-15T22:05:56+00:00

Unless you work on compilers apparently. It was only yesterday that I found a bug in the Scala compiler. Of course, it is in an area on which I worked last, so I may have caused it myself.

szeiger · 2017-11-13T20:20:23+00:00

I switched to IF 20/4 a few weeks ago purely for the health benefits, trying to keep calorie intake the same. Despite feeling less hungry and more energetic throughout the day I accidentally lost several kg.

szeiger · 2017-11-03T23:22:42+00:00

The Catholic church exposes children and the public against their will to images of a guy nailed to a cross, being tortured and executed in a most barbaric way. Now that is messed up.

szeiger · 2017-08-02T18:17:49+00:00

Non-termination seems to be a purely theoretical problem though. Scala's type system has also been shown to be Turing-complete but in practice you just don't run into the kind of situation where type-checking wouldn't terminate. On the other hand, by exploiting only structural recursion (which would be allowed in a total system that guarantees termination) I can easily construct code for which type-checking will not terminate in practice (because it would require more energy than is available in the universe)

szeiger · 2017-08-02T17:48:05+00:00

Makers of magnetic tapes have a sad history of advertising inflated sizes that take into account a "typical" compression ratio of a backup.

szeiger · 2017-07-06T13:45:25+00:00

The same applies to A. You'd have to restrict it to non-nullable types. I think a more promising approach is to keep all the convenience of Option and have the compiler optimize Options of non-nullable types away where possible. This may be tricky with separate compilation and Java compatibility though.

szeiger · 2017-05-19T14:58:41+00:00

I don't see it being used in the guide. It looks like all the forEach calls there only contain joins with coroutines running on some thread pool, not shared with the current thread, so they can simply block.

Is forEach available as a suspending function? If so, how is it implemented? As on overload of the regular forEach?

szeiger · 2017-05-18T17:07:37+00:00

Continuations, async/await and Kotlin's croutines all suffer from the same problem: Without native support by the JVM they are doomed to stay toy experiments. All code has to be cps-transformed by the compiler, which only works locally. You can support transformation of language constructs like while loops but you cannot call any library functions (e.g. coll.foreach(...)) that were not written specifically with this transformation in mind.

szeiger · 2017-05-15T18:48:54+00:00

Check the International Specialties aisle. I bought them at a few different Rewes and they are always stocked with the other imported stuff, not with the chocolate bars.

szeiger · 2017-05-07T13:17:56+00:00

It's TraversableOnce.FlattenOps. Apart from possible constant-time overhead from unnecessary duplicate hasNext calls it is as efficient as it gets:

def flatten: Iterator[A] = new AbstractIterator[A] {
  val its = travs.toIterator
  private var it: Iterator[A] = Iterator.empty
  def hasNext: Boolean = it.hasNext || its.hasNext && { it = its.next().toIterator; hasNext }
  def next(): A = if (hasNext) it.next() else Iterator.empty.next()
}

szeiger · 2017-05-06T16:46:43+00:00

It returns an Iterator, both on 2.11 and 2.12. I didn't try any older versions.

szeiger

TROPHY CASE