Are my problems really so advanced that nobody can help me?
I’d rather suspect, this is not the correct place for such a discussion. ESP32 is much different platform as compared to ESP8266 and it would be better to ask developers of Arduino Core for ESP’s why such a difference. And the ESP32 is obviously less popular device on this forum for a simple reason: most users sees the ESP8266 as “good enough” for their needs, is better supported and cheaper (Yet the ESP’s 32 prices dropped significantly too)
2 Likes
@Phil333 if you decide to take the question to another forum please post a link so that I can follow…very interested in this
1 Like
@ marvin7: it just feels like any issue I have is not possible to solve/answer.
The ESP32 itself is not the problem.
Running the speedcounter without all the blynk stuff makes the ESP32 faster as expected (on Arduino IDE).
Thanks anyway
The ESP32 did come out later in Blynk development, and was not as popular a device due to expressif’s own issues while slowly developing their Arduino Core… so yes, Blynk’s ESP32 library may not be up to Blynk’s ESP8266 library “standards”.
Now, with Blynk 2.0 on the horizon and support for this older version waning… we will just have to wait and see what will or will not get fixed in the future.
It’s difficult to know, from what you’ve written, how much investigative work you’ve done yourself to try to narrow down the cause of the issue.
Personally, I think I’d try some of these things:
- Using different versions of the ESP32 core. If you’re running the latest version then try downgrading.
- Try other types of ESP32 dev boards from different suppliers
- Try Non SSL versions of the Blynk libraries.
- Check that there’s nothing ESP32 specific that can be switched off in your code to give more speed (turning BLE off for example).
- Look at forcing the ESP32 to use its multiple cores differently.
- Research if others are reporting issues in certain situations, to see if this a Blynk library issue of something else.
Threads like this one:
Might be useful when looking at how best to use the multiple cores.
I’ve seen another thread (but I can’t be bothered to search for it) where a community member ran Blynk code on one core and horrible code with blocking delays on another core, just to prove that it can be done without affecting Blynk’s operation.
Pete.
I have the same issue with my PedalinoMini project. When I enable Blynk my PedalinoMini is not very responsive.
When I disable Blynk it is running very smooth.
Regards
alf45tar
I an running my project on a NodeMCU and an ESP32 Wroom with different auth.
ESP32 is 4x faster than my NodeMCU and more stable.
the only weird thing with ESP32 is that I have to reset it , each time power shutdown.
@PeteKnight:
Thanks for the infos!
I have already done a few of your suggestions, as I have:
-
- Tryed other types of ESP32 dev boards from different suppliers
-
- Tryed Non SSL versions of the Blynk libraries.
-
- Checked that there’s nothing ESP32 specific that can be switched off in your code to give more speed (turning BLE off for example).
-
- Researched if others are reporting issues in certain situations, to see if this a Blynk library issue of something else.
I will look and test the other ideas as well.
@Blynk_Coeur:
Can you give me an example of your code so I can verify and check it on my devices?
BTW: I also have a NodeMCU ESP8266 and a NodeMCU ESP32.
The reset appears also to me, but this is currently the least important thing.
It seems like it has something to do with not connecting to wifi after a normal power shutdown.
Maybe a delay on startup will help for this issue to give more time to get everything prepared for the wifi connection. (just a rough guess)
1 Like
@alf45tar This OP seems to be more about whether the Blynk library support for ESP32 is as optimised as the one for ESP8266… and probably a difficult one to determine, as both devices are significantly different architectures from one another.
I don’t see your “issue” as being the same as this OP’s topic… ANY existing process will run slower, or seem less responsive if you add in another timing and communication intensive process to it… that is just common sense.
If you are having issues merging Blynk into your project, please create your OWN topic for it, not tagging into others, Thank you.
1 Like
@Phil333 Not sure if this will assist you in your determination, but I added Blynk (a simple uptime display) to an existing test sketch that runs 24/7. It is just displaying time, date, loop count, random RGB values, CPU temp and RSSI on an LCD screen.
I did discover that adding Blynk.run() to the void loop() slowed it down some…
Without Blynk.run() - around 21500 loop cycles per second
With Blynk run() - around 9900 loop cycles per second
However… the Display widget in the App continued to work even without Blynk.run() in the loop 
Some peculiarity with the ESP32 library?? (and NO, it is NOT anywhere else in the code… there is just a single Blynk command in the SimpleTimer based timed display loop…)
Blynk.virtualWrite(V0, millis() / 1000);
So, when treating the ESP as a single CPU device at least… It seems Blynk does slow somthing down… but removing Blynk.run(), speeds it up without stopping App connection??? Test it and see in your case.
2 Likes
Nice catch Gunner! :D:D
I will test it this evening and report the results.
Looks like the developement state is really “in progress” for the ESP32 
EDIT: I couldnt hold myself for testing this…
Exact the same code except the left side has no Blynk.run(); in it.
Updates to the app every second.
Left side (no Blynk.run) is ~125 times faster!
This evening I will compare the ESP32 again to the ESP8266.
Looks like the table has turned now
maybe you can create 2 tasks using the xTaskCreatePinnedToCore() function 
I also found out, that also the ESP8266 doesnt need the “Blynk.run();” command to actually sync with the server (and also gets faster with not using it).
This is how I tested it in the loop function:
speedcounter++;
if (speedcounter >= 10000)
{
speedcounter = 0;
unsigned long currentSpeedCheckMillis = millis();
Serial.println(currentSpeedCheckMillis - previousSpeedCheckMillis);
previousSpeedCheckMillis = currentSpeedCheckMillis;
}
Here are the results as images:
ESP32:
ESP8266@80MHz
ESP8266@160MHz
In words:
The ESP32 with SSL and Blynk.run() is the slowest. (~3750)
Not using SSL makes it 6.5x faster. (~570)
Without Blynk.run(); it gets another 20x faster. (~28)
The ESP8266 @80MHz is with SSL and Blynk.run() is 4.6x faster than the ESP32 (~800).
Not using SSL makes it 1.6x faster. (~500)
Without Blynk.run() it gets another 3.3x faster. (~150)
The ESP8266 @80MHz is with SSL and Blynk.run() 9.4 times faster than the ESP32 (~400).
Not using SSL makes it 1.6x faster. (~250)
Without Blynk.run() it gets another 3.16x faster. (~79)
Conclusion:
The ESP8266 is pretty constant.
Doubling the frequency makes it pretty solid twice as fast.
Not using Blynk.run() makes the ESP32 incredible 134x faster (3750 -> 28), while the ESP8266 also gets a massive 5.3x boost (800->150).
While the ESP8266 is always fast enough for any tasks (remember that it counts 10000 times before it outputs the time difference in ms), the ESP32 with SSL and Blynk.run() is really on the low side.
3.750s for 10000 cycles makes it very slow 3750µs per cylce.
It is more obvious if you compare it to the possible value of 28ms/10000 cycles, which is only 2.8µs per cycle (and the second core is not even touched).
I hope you found it interesting, because testing everything and taking screenshots was more time cunsuming than I thought 
I hope that a developer jumps into this thread because I doubt that leaving Blynk.run() out, will do a real SSL communication (and maybe some other functionality will be missing).
3 Likes
great work and well explained. I’m sure the Blynk developers will provide us some guidance on this - they are usually right onto it.
For example:
BLYNK_WRITE()
BLYNK_READ()
BLYNK_CONNECTED()
etc.
It’s just a guess, but based on some logical (?) assumptions…
but , without Blynk.run(), how the app can run ?
1 Like
Well, Blynk.run() has always been established as a trigger for the “housekeeping” process, one that keeps the library doing it’s thing as the loop runs. But the Blynk library does work when just commands are processed, as seen in the initial setup and connection commands like Blynk.begin() or Blynk.config() followed by Blynk.connect() so there is a possibility that even just the processing of a Blynk.virtualWrite() command or even the integration of BlynkTimer and timer.run() may be enough to trigger the “housekeeping”? This also may be the result of changes made over time in the current library versions, and thus the “rule” of Blynk.run() in the loop may have changed over time?
But as I am not a developer, nor that skilled at coding to dig into the library at this time, this is mostly an “intellectual” guess.
1 Like
Just a feedback from me:
With NO blynk functions in loop (Blynk.virtualWrite, Blynk.setProperty,
timer.run(), etc) there is nothing send/sync to the server/app.
But if you have at least one of them, then the program acts as if there is a Blynk.run() and is a lot faster.
would be nice to get a clear and concise ruling/description from the blynk developers on this topic 
2 Likes