Test de vitesse Apex – Système Does.Limite de coût du processeur de Debug() ?

Expérience de Test de Vitesse Apex:
Ce blog fait partie des expériences de test de Vitesse Apex.
Ces expériences vérifient-elles que nous faisons quelque chose de mal en écrivant du code? Quelle chose est bonne à écrire ou ce qui ne l’est pas? Votre seule ligne de code tue-t-elle la limite du processeur?
Je fais des expériences tout ce que j’ai trouvé. Vous êtes les bienvenus ici, Si vous avez quelque chose qui peut être ajouté dans ces expériences
#CodeShouldNotEatCPU #CPUScientist

Notre expérience:
Dans cette expérience, nous allons vérifier que si le système.le débogage mange votre temps CPU ou non.

Vous aurez besoin :
D’un ordinateur, d’un navigateur, d’une organisation Salesforce et de 2000 enregistrements de prospects.

Commençons:
Nous avons pris 2000 enregistrements de plomb pour cette expérience. Nous interrogeons ces enregistrements et parcourons une boucle. Créez cette classe dans votre organisation de développeurs.

https://gist.github.com/TheVishnuKumar/fe5b64dd906bb9964ec450f9f403a343

Expérience 1:
Nous n’utilisons aucun débogage dans cette expérience. Ouvrez la console du développeur. Maintenant, Ouvrez la fenêtre Exécuter Anonyme. (Cette option est présente dans le menu Débogage.)
Copiez ce code ApexSpeedExperiment_1.runExperiment1(); et exécutez-le à partir de la console du développeur. J’ai appelé cette méthode 5 fois et voici les résultats.

Résultat : Le temps moyen pris est de 29,2 Millisecondes.

Expérience 2:
Nous utilisons des débogages système dans cette expérience. Ouvrez la console du développeur. Maintenant, Ouvrez la fenêtre Exécuter Anonyme. (Cette option est présente dans le menu Débogage.)
Copiez ce code ApexSpeedExperiment_1.runExperiment2(); et exécutez-le à partir de la console du développeur. J’ai appelé cette méthode 5 fois et voici les résultats.

Résultat: Le temps moyen pris est de 110 Millisecondes.

Conclusion:
Selon nos expériences, Système.déboguer la limite de consommation de CPU.
1. Il est bon que nous utilisions les débogages nécessaires en production.
2. N’utilisez pas de débogage pour la réponse de l’API. Comme les réponses des API peuvent être trop grandes.
3. N’imprimez pas l’instance d’enregistrement entière lors du débogage.
4. Si de gros débogages sont nécessaires, utilisez un paramètre personnalisé en production pour imprimer des débogages. Exp:
if(isDebugOn) {
système.debug(‘Votre débogage’);
}
5. Supprimez les débogages indésirables avant de déployer le code en production.

Remarque : Si la journalisation est désactivée, l’appel se produit toujours. Si une ligne de code écrite dans le code sera exécutée et le temps d’exécution sera compté.
Selon le document du développeur Salesforce :
Si l’argument msg n’est pas une chaîne, la méthode de débogage appelle String.valueOf pour le convertir en chaîne. chaîne.La méthode valueOf appelle la méthode toString sur l’argument, si disponible, ou toute méthode toString remplacée si l’argument est un type défini par l’utilisateur. Sinon, si aucune méthode toString n’est disponible, elle renvoie une représentation sous forme de chaîne de l’argument. Si le niveau de journal du code Apex est défini sur DEBUG ou supérieur, le message de cette instruction debug sera écrit dans le journal de débogage.
Ce processus ci-dessus consomme du temps CPU.

Merci d’avoir participé à l’expérience de test de vitesse Apex. Si vous avez une autre expérience en tête. Faites-le moi savoir. Je vais mener une expérience et partagerai le blog ici.

Posté le 0to1Code.Com

You might also like

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.