A lot of vlang-related statistics are very suspicious, probably some of the metrics are boosted by a click farm or something similar. For example, 99% of the global google searches about "vlang" are from Beijing.
https://trends.google.com/trends/explore?date=today%205-y&q=...
This makes very little sense to me. Keep in mind that Google is blocked in China, and has been for a long time, except maybe specific special machines from the government that may have unlimited access. Even if there is a lot of search interest from people using VPNs, it shouldn't show up as China.
So I'm not sure if that's evidence of metric boosting by a click farm, or anything else. Clicking on the question mark, it looks like it's not really a ranking of "where do searches come from", but rather "how popular is it in this region":
> Numbers represent search interest relative to the highest point on the chart for the given region and time. A value of 100 is the peak popularity for the term. A value of 50 means that the term is half as popular. A score of 0 means there was not enough data for this term.
Was curious, so checked up. V has Chinese contributors[2] and who have also translated their documentation from English to Chinese[1]. As was mentioned, other languages have Chinese followings too.
I opened a PR to use the more precise timers. This would not improve the performance of any of the tests, but it will improve their time accuracy.
I highlighted some other problems related to the Lucene benchmark, but since I can't program in Clojure I can't fix them with a PR: I opened 3 issues to describe what can be done to address them.
Merged your PR. Thank you! If you do not know Clojure, that's fine, just outline what you want to do in Java, I can translate that into Clojure. Thanks.
To be honest, all your proposed changes would not make material difference, for algorithmic differences cannot be made up by implementation details.
As has already been demonstrated, T-Wand is implemented in a much slower language, Clojure. Clojure is implemented on top of JVM, it cannot possibly beat the same algorithm written in optimized Java. The only way to make a difference is to change the algorithm. So all your suggestions would not make a difference.
You completely misunderstood what this project does.
This kind of libraries do not force you to return results in a specific way.
Generally they allow the programmer to customize how the results are scored and chosen.
There's the kind of library Lucene wants to be, a configurable library. But there are other libraries do not want that.
In this case, Datalevin is a database system, full-text search is just but a feature, I do not want users to configure full-text search in Datalevin as much as they like in Lucene. I want the default to be good, which Lucene's is not.
That's not true. The real problem is that he is implying that his software is faster than Lucene showing data from a benchmark that has substantial flaws.
The reason why the majority of criticism comes from Lucene users is because they generally have a higher knownledge about this field than the people that read this article without having the basic knowledge to form any kind of criticism
Incorrect. The benchmark is fine. Your so-called "fundamental" flaws are just superficial things, such as using a different time measure, using a different benchmark library, passing in a thread pool, and so on. These are immaterial for relative comparison, unless proven otherwise.
I have repeated asked you to send the code that does things properly in your mind, and you refused to do so.
So you are just trolling. Please stop hinder the progress of the industry through pointless trolling. Makes some positive contributions instead, and I have pointed out repeatedly how to make a positive contribution in this case. Please do.
You are a university student, I am a seasoned computer scientist, past researcher and professor, I am busying running a startup. This will be the last time I will say this to you: please consider contributing something positive to the world.
I already explained to you why I didn't open more than one PR to the project, I'm not trolling anyone:
without knowing Clojure the only contribution that I could do without spending literally days of work is just the use of System.nanoTime() instead of System.currentTimeMillis().
The reason why I don't write the other benchmarks in Java is because reimplementing anything from zero costs precious time, that I don't have.
If you don't have time too, instead of closing the issues and calling me a troll, you can just say that; you are taking some valid critiques as a personal attack.
It's true that I'm just an university student and you are a scientist, a researcher, a professor, and an enterpreneur, but it doesn't mean that I can't be knowledged as you in very narrow fields. I'm currently running a personal project that uses Lucene since four years ago, with about 8 billion messages and 340 million chats stored in a distributed lucene index, so I'm not the regular troll or a person that just talks without knowing anything. I surely can't critique your T-WAND algorithm, that it seems to be good in your use case, but with all the humilty in the world I can say to have the minimum knowledge required to spot some weird usages of Lucene APIs.
As I have repeated suggested, since you obviously know Lucene, it does not take much for you to write a few lines of Java code to say, "here, this is how it is supposed to be done".
Instead, you keeps giving all kind of excuses. You said you do not have time, but somehow you have time to write long wall of text like this. If you are not trolling, what you are doing then?
I pointed out to you why your suggestions will not make differences, some I have already tried. For example, initializing a query parser only once, but that would crash Lucene. Clearly, you do not know about this, so your knowledge of Lucene is not as good as you think you know.
I would appreciate if you also send a PR to address these issues, since clearly you know more about benchmarking than me.
Contributing to open source project is good, right?
BTW, Lucene is an open source project, Datalevin is also an open source project. Contributing to either would be equally good.
Even if you only want to contribute to Lucene for some reasons, a better contribution would be to integrate T-Wand in Lucene, rather than trying to talk down Datalevin. Would you agree?
I never had the interest to "talk down Datalevin", I criticized the results because the title was quite misleading in the tones and the benchmarks were not rigorous enough to express conclusive statements.
Looking at gitly repository it almost has no features, only a fraction of the basic git features are present, and they are barely working.
Why is it being advertised here on HN as a fast alternative of github/gitlab?
P.S.: Probably the website crashed, it's giving me 502 bad gateway from cloudflare
