#Python – Let’s use a #FaceRecognition demo app for a performance comparison between #RaspberryPi3 and #RaspberryPi4


I started to do some tests with the new Raspberry Pi 4 and the results are amazing. I’m not a performance expert, so I decided to pick up some of the demos / apps I’ve creating for the Raspberry Pi and run them in both models: Raspberry Pi 3 B+ and Raspberry Pi 4.

I started with an amazing set of tutorials on how to perform Face Recognition from Adrian Rosebrock (see references). I’ve been using his Face Recognition python package for this scenarios and it’s an amazing one.

I added some code to a custom version of Adrian’s Face Recognition sample, and it looks great. The main idea was to track in real-time the current FPS (similar to the work I did with the Image AI and Hololens sample a couple of days ago, see references).

This sample load a file with 15 trained faces and analyze frame by frame to

  • Detect faces in the frame.
  • If a face is detected, draw a frame around it.
  • For each detected frame analyze if the face is a trained face.
  • If the face is part of the trained dataset, the app will add the name of the person on top of the frame.

I display in real-time the FPS processed with a USB camera in a Raspberry Pi 3 B+. Doing a lot of tweaks and getting the best performance in the device I could never process 1FPS. The average processing data were between 0.6 and 0.9 FPS in a Raspberry Pi 3B+.

python face recognition in raspberry py 3 with FPS live

IMHO, these results are great for a small device like a Raspberry Pi 3B+. But now it was time to test it in the new Raspberry Pi 4. And an important note here is to remark that even if I did this tests in a Raspberry Pi 4 with 4GB of Rams, the performance results are similar to a RPI4 with just 1 GB of ram. We have more memory, however the processor improvements are quite significant in the new version.

I installed all the necessary software in the Raspberry Pi 4 and I got 3X better results. I’ve even tun this in a 1080p resolution to get a sense of the real processing time. The average processing data were between 2.3 and 2.4 FPS in a Raspberry Pi 4.

python face recognition in raspberry py 4 with FPS live

Amazing! In this scenario the Raspberry Pi 4 is almost 3 times faster than the Raspberry Pi 3. And again, these are amazing times for a 50USD device.

The sample source code is https://github.com/elbruno/Blog/tree/master/20190819%20Rpi%203%20vs%20Rpi%204%20Face%20Recognition

I even have time for some BBQ time with family and friends!

Happy coding!

Greetings @ Toronto

El Bruno



#VSCode – Let’s do some #FaceRecognition with 20 lines in #Python (6/N)

Hi !

I’ll start with my posts

  1. Detecting Faces with 20 lines in Python
  2. Face Recognition with 20 lines in Python
  3. Detecting Facial Features with 20 lines in Python
  4. Facial Features and Face Recognition with 20 lines in Python
  5. Performance improvements with code

In my last post I share some lines of code which allowed me to run some of the face recognition demos 6 times faster. I added a Frames per Second (FPS) feature in my samples. Later, thinking about performance, I realize that I don’t need to work with a full HD picture (1920 x 1080), so I added some code to resize the photo before the face detection process.

However, while I was coding arond this solution I also realized that I may want to initialize my camera to start in a lower resolution. So, I searched online on how to do this with OpenCV and I found 3 beautiful lines of code.

open camera with opencv with lower resolution

So, I manage to improve my processing code from 20FPS to +30FPS … which is very good ! Later on this posts I’ll try to do some similar FPS tests on a smaller device and I’ll see and share how this works.

Happy Coding!

Greetings @ Burlington

El Bruno


#VS2017 – Disable PerfWatson2 to improve Visual Studio performance from the Visual Studio Experience Improvement Program (What?)

Hi !

Next month, this post will be a 7 years old post

[VS2010] 5 tips to improve your IDEs performance

And the truth is that, with the exception of the WinForms option, the other options are still valid. Visual Studio is still an excellent IDE, if you can live with a high RAM usage and warm processor.

Well, thanks to a tweet from RFog referring to a tweet from Enrique Blanco

I learn that to kill the 2nd PerfWatson2.exe instance, which is usually associated with the IDE, you have to unsubscribe from the Visual Studio Experience Program (yes, you have not misread that)

In the StackOverflow post they explain it perfectly

  • From the help menu, select Send Feedback > Settings.
  • In the Visual Studio Experience Improvement Program dialog, select No, I would not like to participate.

I have been a little flipping with this option, although I see the good side: my demos with my crappy surface pro 4 will be much more fluid!

Greetings @ Burlington

El Bruno


#VS2017 – Deshabilitar PerfWatson2 para mejorar la performance en Visual Studio desde el programa de mejora de experiencia de usuario (What?)


En un mes se cumplirán 7 años del siguiente post

[VS2010] 5 tips to improve your IDEs performance

Y la verdad es que, salvo la opción de WinForms, las demás opciones siguen siendo válidas. Visual Studio sigue siendo un excelente IDE, si puedes vivir con un consumo alto de RAM y el procesador calentito calentito.

Pues bien, gracias a un tweet de RFog haciendo referencia a un tweet de Enrique Blanco

Me entero que para matar la 2da instancia de PerfWatson2.exe que suele estar asociada al IDE, hay que darse de baja del programa de experiencia de usuario (tal cual, no has leido mal)

En el post de StackOverflow lo explican perfectamente

  • From the help menu, select Send Feedback > Settings.
  • In the Visual Studio Experience Improvement Program dialog, select No, I would not like to participate.

Me he quedado un poco fliping con esta opción, aunque le veo el lado bueno: mis demos con mi crappy surface pro 4 serán mucho mas fluidas!

Saludos @ Burlington

El Bruno


VS2017 – Improving the solution load time


Today I found another new cool feature in Visual Studio 2017. This one is related to the load time in “big solutions”. I had read about this, but it had not checked this out it and just today, when I saw the following message, had the interest to read about this feature.


Load <Solution Name> faster next time by trying out lightweight Solution Load. Some IDE features and extensions may not be available.

As well explained in this Visual Studio post (link), it is possible to change the default behavior for solution inside Visual Studio options


Or, on overwriting the global settings of the IDE, since the properties of the solution


When we enable this “LightWeight Load” mode, Visual Studio will disable some features until we need them for 1st time, and thus the solution will load faster.

For example:

  • The projects are loaded as they are needed.
  • NuGet packages restore is not activated during the build.
  • There is no background solution prebuilt, so the design of XAML view are not available.

The 1st option is related to property already handling Visual Studio from making several versions: “LoadIfNeeded”. On this subject, I already wrote a post a while ago, and in it he reviewed a very useful extension for these scenarios.

Greetings @ Toronto

El Bruno


#VS2017 – Mejorando el tiempo de carga en nuestras soluciones

Hola !

Hoy me encuentro con otra novedad en Visual Studio 2017 relacionada con el tiempo de carga de soluciones “grandes”.  Algo había leído al respecto, pero no lo había registrado y recién hoy, cuando vi el siguiente mensaje, tuve la inquietud de volver a leer sobre esta feature.


Load <Solution Name> faster next time by trying out lightweight Solution Load. Some IDE features and extensions may not be available.

Como bien explican en este post de Visual Studio (link), es posible habilitar de manera global el proceso de carga de las soluciones desde las opciones de Visual Studio


O, sobre escriiendo las settings globales del IDE, desde las propiedades de la solución


Cuando habilitamos este modo “LightWeight Load”, Visual Studio desactivará algunas funcionalidades hasta que las necesitemos por 1ra vez, y de esta forma la solución se cargará más rápido.

Por ejemplo:

  • Los proyectos se cargan a medida que se necesitan los mismos.
  • No se activa el restore de packages NuGet durante las build.
  • Al no precompilar en background la solución, las vistas de diseño de XAML no están disponibles.

La 1ra opción está relacionada con la propiedad que ya manejaba Visual Studio desde hacer varias versiones : “LoadIfNeeded“. Sobre este tema, ya escribí un post hace un tiempo, y en el mismo repasa una extensión muy útil para estos escenarios.

Saludos @ Toronto

El Bruno


#VS2017 – Analyzing the performance impact of extensions, panels, and solutions in Visual Studio IDE

Hello !

A few days ago in my podcast review of Connect 2016, I talked about Visual Studio 2017 new features. One of the features that have caught my attention these days is the ability to analyze the performance of VS2017 IDE when we are using extensions, the use of panels and the Solutions load time.

For example, after a while using VS2017, when I open it I find the following message related to ReSharper.



I can see the “extra” time that ReSharper adds to the Visual Studio 2017 load process. At the beginning, it was more than a minute, but after a couple of adjustments I managed to lower that time about 20 seconds.


Another interesting feature is Visual Studio does the same analysis for internal tools like IDE panels such as Team Explorer. In this case, it is detected that it impacts the initial load of Visual Studio because when connecting and refreshing Visual Studio Team Services, it seems that the times are not optimal.


And, what should be the 1st paragraph of this post. The way to access this functionality is through the menu “Help // Manage Visual Studio Performance”


Greetings @ Toronto

El Bruno