Working on a profiling/benchmark tool for the django template language. Looking for feedback on my work so far.
Hi all, I talked with FunkyBob on IRC a few weeks ago and told him I was interested in optimizing the template language. One of the suggestions he made was to make a profiling/benchmarking framework to test changes. While I wouldn't call it a framework yet I have a script set up to run the django template language on a few simple templates and profile individual functions. Right now I have the render(), context(), and Template() methods added but definitely plan on adding more. You can read more on the github page to learn the exact commands but the script can run individual test cases and print out a pstats log. By specifying -o you can also create a callgraph. At this point I'm looking for ways to improve. Right now the script implementation is kinda messy. https://github.com/inondle/django-template-benchmark The main thing I want to improve is the way that test cases are run and implemented. To add a test case in this implementation you would have to: - Write a function and decorate it with @cprofile - Create a new elif statement at the bottom and check for a keyword - Run the script with -t While this isn't a terrible work flow it leaves a lot to be desired. I would like to make it more like how the unittest module works with a setup and test method but rather than checking assertions it just profiles the code and prints out a pstats log for each test case. The pstats log can then be rendered further into a call graph or something else. I've tried to build a profiler class which uses method introspection to run tests but it gets really complicated really fast. I've looked online and can't find a way to subclass or extend the unittest module to do this. Is there a way that I could get the feel of a unittest module but for profiling code instead of running unit tests? I also need to improve the templates that I run. Right now they are very simple and only render a few lines with a pretty minimal context. If anyone has suggestions on test templates I'm all ears. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/cdc48345-84dd-4010-bf4a-7527b317ab12%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Organizing the built-in system check framework's hint messages
Hi all, Recently I was trying to fix a bug that required me to alter the hint message of the `fields.E306`[1] system check error[2]. The bug in question added a condition to a check which if failed caused the instantiation of a `django.core.checks.Error` object. In order to change the `Error`'s hint properly I would have to change the hint in 3 different places. Once where the `Error` was instantiated, in the documentation, and in it's tester. This was a rather tedious task and if done improperly can lead to differing error messages. Rather than just passing the hint in as an argument to the constructor I think it would be better if the Error object had the option to lookup it's error messages rather than just having them given. It wouldn't take much effort to create a dictionary of `id: message` pairs which `Error` objects could use to lookup their messages/hints. In the event that an `Error` is instantiated with no hint/message given it could perform a quick check to see if it is logged in the dictionary. This would not add any significant overhead to the process and eliminate some possibility of human error. This situation becomes even more tedious if you have more than one place where the error is instantiated or tested. This could also help with documentation because all of the builtin error messages would be stored in a central location. In any case, let me know what you guys think. I know its kind of a non-issue as the current system works fine. I just thought there was some room for improvement. Thanks! [1] https://docs.djangoproject.com/en/1.9/ref/checks/#fields [2] https://docs.djangoproject.com/en/1.9/topics/checks/ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/07d224fa-4b73-4450-97f2-3c0a2214ea36%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Organizing the built-in system check framework's hint messages
Here is a super quick proof of concept that I put together. I just branched my fork of django and added a little to it. Here is the comparing changes page[1]. Quick summary of changes: I created a dictionary that would contain the (id: message) pairs. I also modified the CheckMessage.__init__ method so that it will attempt to find a hint message for the id that was passed to it. If no key was found then it continues as normal. This allows me to comment out the hint parameter when it is created but still be able to pass when it is run through its normal tests. [1] https://github.com/django/django/compare/master...inondle:hints On Thursday, May 19, 2016 at 10:55:15 AM UTC-7, Tim Graham wrote: > > The security checks errors are defined as module level constants to avoid > some redundancy since these can be imported in tests: > https://github.com/django/django/blob/0eac5535f7afd2295b1db978dffb97d79030807e/django/core/checks/security/base.py > . > > If you feel your approach would be an improvement, maybe you could put > together a quick proof of concept so it's a bit easier to understand? > > On Wednesday, May 18, 2016 at 11:50:47 PM UTC-4, Quentin Fulsher wrote: >> >> Hi all, >> >> Recently I was trying to fix a bug that required me to alter the hint >> message of the `fields.E306`[1] system check error[2]. The bug in question >> added a condition to a check which if failed caused the instantiation of a >> `django.core.checks.Error` object. In order to change the `Error`'s hint >> properly I would have to change the hint in 3 different places. Once where >> the `Error` was instantiated, in the documentation, and in it's tester. >> This was a rather tedious task and if done improperly can lead to differing >> error messages. Rather than just passing the hint in as an argument to the >> constructor I think it would be better if the Error object had the option >> to lookup it's error messages rather than just having them given. >> >> It wouldn't take much effort to create a dictionary of `id: message` >> pairs which `Error` objects could use to lookup their messages/hints. In >> the event that an `Error` is instantiated with no hint/message given it >> could perform a quick check to see if it is logged in the dictionary. This >> would not add any significant overhead to the process and eliminate some >> possibility of human error. >> >> This situation becomes even more tedious if you have more than one place >> where the error is instantiated or tested. This could also help with >> documentation because all of the builtin error messages would be stored in >> a central location. >> >> In any case, let me know what you guys think. I know its kind of a >> non-issue as the current system works fine. I just thought there was some >> room for improvement. Thanks! >> >> [1] https://docs.djangoproject.com/en/1.9/ref/checks/#fields >> [2] https://docs.djangoproject.com/en/1.9/topics/checks/ >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/307a5a2f-5494-4a4f-8b55-d1ddbec3d94f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
