1

My code does the following:

1) Defines a somewhat large dictionary

2) Uses the requests library to send a post request with the dictionary to a webserver.

If I set the dictionary up as a class variable (class is defined within the same .py file) and later reference it through its member function (called by main), it takes significantly longer to execute (about half-one second longer when timed).

However, if I define the dictionary within the scope of the class's member function, it executes half-one second faster.

Can someone explain why this happens? I've asked around and googled; it seems like interpreted languages like Python don't execute like compiled languages in the sense that there's a parsing process that's done by the interpreter that slows down runtime.

EDIT: Some code (of the first method, second method simply moves the dictionary into the scope of myClass.theFunction())

import requests

class myClass():
    def __init__(self):
        ...Other member variables...
        self.user_session = requests.Session()
        self.myDict = { 'key1': 'value1',
                    ....
                    'key30': 'value30'
                  }
    def theFunction(self):
        ....some parsing stuff...
        session_post = self.user_session.post(url=self.URL, data=self.myDict,
                                              headers=self.headers)
        print session_post.status_code

if __name__ == '__main__':
    instance = myClass()
    instance.theFunction()
martineau
  • 119,623
  • 25
  • 170
  • 301
Moo
  • 85
  • 1
  • 1
  • 6
  • 1
    Your question title is about accessing a dictionary via a class, but in your question text you describe a much more complicated situation that involves making a web request. Can you reproduce the slowdown in a self-contained example that doesn't involve making any remote requests? – BrenBarn Sep 17 '16 at 01:54
  • 3
    You're going to need to provide code; there are some inefficiencies in runtime lookup, but not the sort that involve half a second or so of overhead outside of the hottest of hot loops. In those cases, sometimes caching to a local variable is useful, but we'd need to see what you've actually done. – ShadowRanger Sep 17 '16 at 01:55
  • @BrenBarn I think I've ruled out the variance in server response time, at least somewhat, by running the code ~25 times with each method and averaging out the time. – Moo Sep 17 '16 at 02:00
  • @ShadowRanger Adding some snippets in a sec. – Moo Sep 17 '16 at 02:01
  • 1
    Nothing you posted would explain the slowdowns you describe. Also, you name the member `session` in `__init__` but referenced `user_session` in `theFunction`, so I'm worried you missed some important stuff (or just had copy'n'paste fail). – ShadowRanger Sep 17 '16 at 02:12
  • @ShadowRanger Corrected that, cp fail heh. On further reflection, it could be how the requests.post (or get) function references the payload data. The slow down might not be at the level of python's interpreter, but from the library's design. Also corrected the question for specificity. – Moo Sep 17 '16 at 02:15
  • 1
    @Moo: BTW, when microbenchmarking, the common practice is not to average times, because that gets all sorts of wonkiness averaged in. Take the best time; that's usually more representative of the "real" cost (with the fluctuation being lots of background nonsense that you have little/no control over). The `timeit` module's `repeat` function is good for eliminating many sources of timing jitter, and taking the `min` result from `timeit.repeat` with a `repeat` count of 5 and a `number` count of 5 (or for network requests, `repeat=25`, `number=1` maybe) would give you a more useful baseline. – ShadowRanger Sep 17 '16 at 02:18
  • 1
    BTW, the dictionary is not a "class variable", it's an instance variable (or attribute). – martineau Sep 17 '16 at 02:25

0 Answers0