Per-Åke Minborg

The tools used has similar features like warmup and making sure that produced results are actually used preventing erroneous dead-code elimination.

Hi and thank you for your question Oleksandra.

EDIT: For JOIN it is not possible to compose predicated. So, currently, you can only join on one condition. There is an issue for this: https://github.com/speedment/speedment/issues/724

For the case with .filter() All predicates support AND, OR and NEGATE. So you could, for example, write "Film.LENGTH.greaterThan(100).or(Film.LENGHT.lessThan(10))

No worries. It shows that you thought about the article, which is good!

I am afraid that is not the case. The `Stream<String>` is collected to a `List<String>` using the terminating operation `.collect(toList())`.

So the type of `list` is actually `List<String>`.

Interesting proposal. There are also some extra intermediate operations that were added in Java 9.

Thanks for your reply. I am not sure what you don't agree with? The benchmarks are facts and not opinions.

However, you are perfectly right in pointing out that performance is likely to vary significantly for cold code for the different solutions. It is explicitly stated in the article that cold code was not tested. You are also right that "it depends". I only tested a very limited set of iteration constructs and other problems might present other conclusions. The article made no representation as to the general performance of all iteration problems. It did, however, mentioned that Streams are likely to be generally used and that was clearly marked as an opinion.

Regarding caches, the problem did not access memory but that would be interesting to test in another article.

That is true and my intention in the article was to make that obvious. The point is that sometimes cleverness can beat raw computational power.

HashMap is not thread-safe and should not be shared across threads. Thus, the rehash is not designed for multi-threaded access. Use ConcurrentHashMap or protect the HashMap by Collections.synchronizedMap() instead.

Thanks for your comment.

If you know how to use Declarative coding, you are a better programmer. That does not mean that Declarative coding is better than Imperative coding in every case and aspect.

I fully agree with you that knowing the right choice is key.

You bring up an interesting aspect: Imperative vs. Declarative Performance. I am planning to write an article about that in the future. In some cases, Declarative may, in fact, be faster than Imperative contrary to what many people believe. Stay tuned.

Nicolai Parlog pointed out to me that this is only true for Java 8. Subsequent Java versions actually short circuits List streams where count() is the only operation.

Correct. It was in reference to the old one. The new syntax allowed "case 2,3,4,4,5:" and that is why I didn't spot it in the first place. The old switch became the new switch...

You are right. Thank you for pointing this out! I have updated the code according to your comment.

You can create a view or you can programmatically select any number of rows at load time (e.g. just load items from this year) and/or elect to fill in just certain columns. With the UI Tool (or by editing the speedment.json file) you can select what columns should be included in your data model (e.g. you might only need a subset of the columns in your application).

You can also create "virtual columns" that is a kind of a programmatic view of the database. Useful if you are not allowed to touch the database.

This is described in the manual here: https://speedment.github.io/speedment-doc/datastore.html#loadreload-individual-rows

A single snapshot can serve an infinite amount of queries. Loading of new snapshots occurs in the background.

In this example, initial loading of the entire Sakila database snapshot took about one second.

The benchmarks did not include the load time. If we would have amortized the initial load time over the many million times of calls that were made during the benchmarks, the latency result would be affected but not by much.

I should have pointed out this in the article. Thanks for your comment.

I don't know but I have seen it since 2017. It was probably there before.

Here is a Gist of the class I used: https://gist.github.com/minborg/aa7b8fcf7c6455b182a5b61fb32c4a19

The version used in the article was Speedment Free which can be used at no cost. Here is a link to the licensing model: https://www.speedment.com/pricing/

You get type safety and,arguably. ease of use. In this example, performance is not an issue. For performance sensitive applications you could use Speedment Enterprise where aggregations cen be performed in-JVM-memory and off-heap.

The objective was to do everything i Java and not use SQL. The problem can of cource be solved in many ways including writing pure SQL with JDBC. Java provides a type safe way of expressing database queries. I also think writing a parallel solution would be much harder using pure JDBC. Differenrt solutions have different pros and cons so it depends on the problem at hand which is the best. This is just one way of doing it.

Thanks for the article Václav. Speedment now supports transactions as per 3.0.17

Thanks for your article. It is true in one sense that all objects are created on the heap. It might be worth mentioning that the JVM can use Escape Analysis to determine the scope of existance for an object. If the scope is "local" the JVM can allocate a representation of an object on the stack rather than on the heap. This way, allocation and cleanup of objects are sped up. Read more here https://dzone.com/articles/overview-of-javas-escape-analysis

Thanks. I have fixed that now.

Big thanks to @tagir_valeev who wrote a benchmark that tested the performance of the scheme. Tagir arrived at the conlcusion that the old fashoned way of initilaizing map is orders of magnitude faster. As I have mentioned, this is just an academic "feature". Do not use it in production code.

See the entire benchmark here: https://gist.github.com/amaembo/cbe9e1a8f3f8d240beb080343670f0c2

Nothing is wrong with your example. In fact, the old way is much faster and more robust. The article just points out another way of dooing it that is unusual and perhaps unexpected. It is of academic interest but have less practical use. I should have made that more clear in the article.

Very interesting Valery. Thanks for the update!

Thanks. Performance can be made better but at a slight cost of complexity. As you say, the key needs to be retrieved twice and there are also som reflection parts that can be optimized. The article is jwritten just to point out that it is possible to do this.

Title uppdated.... :-)

The reason for mentioning examples in the JDK was to show that this is, in fact, a way that is being used regurlary (as oppsed to some comments I have received). You are right that there were many historic blunders in the JDK and is is likely that we will see more of them in the years to come. The same is true for the comment on non-static methods which was not understood by some readers. I agree with your view on the title and I have added a link in the post to Ferencz's original post. Thank you for your comments.

Check out Speedment on GitHub where streams are used for querying a database. The streams are guaranteed to close automatically regardless of how they are used, thus eventually freeing up any I/O resources they may hold. I agree that libraries like RXJava is more sutable than streams for the class of problems you are describing.

Thank you for your feed back. I have corrected the typos pointed out in some of the comments above. The use of static factory methods in interfaces has become more or less a standard within the JDK itself. For example, the Stream interface contains a number of static factory methods that will create a sutable instance of a class that implements the Stream interface. This is also true for many interfaces in the java.util.function package. It should be noted that the interfaces are unaware of the implementation classes for all non-static methods which is important.

The implementation of ConcurrentHashMap looks completely different i Java 8. It would be nice wilth a follow up post on how the Java 8 version works too.

Check out open-source Speedment https://github.com/speedment/speedment which allows you to generate a domain model automatically from an existing database (you can control the code generation) and use Java 8 streams to query the database.

I think your example with casting should have been mentioned in the article too.

Fixed. Sorry.

Hi Francisco! You need to re-generate the code if you want to see new columns for example. As long as you do not remove columns that are being used by Speedment, you can change the database while in operation. You could share your experience and perhaps come with improvement suggestions at gitter: https://gitter.im/speedment/speedment

Correct. And you could even do composed predicates like this:

.filter(Hare.AGE.greaterThan(8).and(Hare.NAME.startsWith("Ha"))

Version 2.2.0 is out now with the Date bug fixed. Read about the new features on https://github.com/speedment/speedment/releases/tag/2.2.0

Hi Roman. Thanks for your input. Speedment CAN generate code from tables with composite primary keys, for example when you have a many-to-many relation table where the relation columns both form the primary key.

Also, the built in stream implementations are much SMARTER than the default streams. So, if you for example filter on an expression, the stream will detect that and it will construct a query that reflects that filer. For example, if you do:

users.stream().filter(User.ID.between(10,20)).filter(User.NAME.equals("John").

then you will stream over:

select id,name,age from user where (id between(10, 20)) and (name='John')

This way, you avoid streaming over the entire table.

It is CORRECT that Speedment cannot generate code from tables with no primary key. Speedment requires that the database is reasonably normalised(e.g. all tables must have a primary key). This is needed, for example, for in-memory caching. It is possible to use a synthetic primary key though if needed.

It is also CORRECT that there is a bug in the current version (2.1.2) that prevents the usage of Date columns. This is fixed and will work with the new upcoming release (2.2.0). Sorry for that! :-)