Congratulations, @admin, Kantu 3.8.7 is by far the slowest version ever! :)


#1

Hey, @admin! You know, it really disappoints me, that not only you ignored the existing performance issues, but you even managed to make it 5 times worse than it was. First of all, I’ll start by mentioning that because of your ignorance I had to buy a new PC, so that my scripts would run at a decent speed and to be honest my plan worked out pretty well. However, today I saw a new version and I don’t know what have you changed by adding that OCR stuff, but you have successfully made Kantu slower on the new PC than it was previously on the old PC, and not even Chrome restart works now, WELL DONE! :clap:

I understand that you are excited with all those OCR features, but keep in mind that most of users do not even use them, so instead of making the Kantu slower and slower with all this image recognition stuff why can’t you just make the OCR as a separate module and keep the original Kantu as slim and optimized as possible? :wink:

Anyway, I am not here to tell you what to do, all I wanted to say is that when I first found this project - I really felt that it could become the greatest free automation tool, but now with every update you just keep ruining it and the funniest thing is that in order to keep the older Kantu version we must pay $299, which is just insane. You know, as a business owner, I’ll tell you something - if you really want to earn money from this project then start working on the performance issues instead of adding useless (to most users) features or else this project will slowly die. That’s just my two cents. :slight_smile:


#2

Well, the good news is that I 100% agree with you: Kantu must not get slow with the updates. :smiley:

In our tests nothing gets slower with this release. So I am surprised by this post. If you don’t use an OCR command, the new code is not touched or used in any way. Of course, bugs can happen, but if there is one, we have not seen it yet.

My assumption for now is that something else is going on on your machine. But if you have a test macro that runs slower now than in an earlier version, please post it here and we will fix it asap. You probably know it already, you can measure the macro runtime with the !runtime variable.

and the funniest thing is that in order to keep the older Kantu version we must pay $299, which is just insane

That is not correct. You can continue to use old Kantu versions forever for free. You find all old versions in our archive. If you install the extension from the file, Chrome and Firefox do not auto-update it.

The Kantu Update Management feature is part of the Enterprise Edition. It allows users to easily manage and control Kantu updates. This feature requires a custom setup for each organization, therefore we can not offer it for free. It is a great feature, and we highly recommend the Enterprise Edition for users that use Kantu commercially. But it is not required just to keep and use older Kantu versions.


#3

@admin thanks for the archive link, was looking for it but couldn’t find nowhere on the website. So, after installing 3.7.2 I can confirm that the issue is not from my side, because the 3.7.2 version runs like a charm. Now, I cannot post the script, because it is my private project on which I worked for almost a year, but after doing more tests it seems that every macro is running slower as if the !replayspeed would be somehow set to medium or even slow instead of fast. I’m really surprised that no one has noticed the performance slowdown. Maybe you could identify the problem by also installing the 3.7.2 and running the same script (for example DemoCsvReadWithWhile) on both versions and checking the !runtime variable?


#4

You are correct. There is clearly something wrong in the new version. It almost looks like some forgotten debug or test code that delays everything. We will investigate this and roll out an update asap. Thank you for finding and reporting this problem!

Some test data:

Runtime V3.8.7 (“New”)

  • DemoCsvReadWithWhile, 28.25s
  • DemoStoreEval, 17.37s

Runtime V3.7,2 (“Old”)

  • DemoCsvReadWithWhile,18.21s
  • DemoStoreEval ,8.34s

Runtime test code:

   {
      "Command": "store",
      "Target": "${!runtime}",
      "Value": "r"
    },
    {
      "Command": "echo",
      "Target": "runtime=${r}",
      "Value": "green"
    },
    {
      "Command": "store",
      "Target": "${!macroname}",
      "Value": "!csvline"
    },
    {
      "Command": "store",
      "Target": "${r}",
      "Value": "!csvline"
    },
    {
      "Command": "csvSave",
      "Target": "runtimelog",
      "Value": "!csvline"
    }

#5

You are welcome, I’m glad I could help, because the performance issues are the most annoying ones so I really hope you will be able to fix all of them. :slight_smile:


#6

We released V3.8.8 just now. It fixes the performance issue. Thanks again for reporting it!