{"action":"created","issue":{"url":"https://api.github.com/repos/textile/python-textile/issues/25","repository_url":"https://api.github.com/repos/textile/python-textile","labels_url":"https://api.github.com/repos/textile/python-textile/issues/25/labels{/name}","comments_url":"https://api.github.com/repos/textile/python-textile/issues/25/comments","events_url":"https://api.github.com/repos/textile/python-textile/issues/25/events","html_url":"https://github.com/textile/python-textile/issues/25","id":150233296,"number":25,"title":"Incredibly abysmal performance.","user":{"login":"amcgregor","id":76750,"avatar_url":"https://avatars.githubusercontent.com/u/76750?v=3","gravatar_id":"","url":"https://api.github.com/users/amcgregor","html_url":"https://github.com/amcgregor","followers_url":"https://api.github.com/users/amcgregor/followers","following_url":"https://api.github.com/users/amcgregor/following{/other_user}","gists_url":"https://api.github.com/users/amcgregor/gists{/gist_id}","starred_url":"https://api.github.com/users/amcgregor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/amcgregor/subscriptions","organizations_url":"https://api.github.com/users/amcgregor/orgs","repos_url":"https://api.github.com/users/amcgregor/repos","events_url":"https://api.github.com/users/amcgregor/events{/privacy}","received_events_url":"https://api.github.com/users/amcgregor/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2016-04-22T01:00:55Z","updated_at":"2016-04-24T20:34:45Z","closed_at":"2016-04-22T02:31:58Z","body":"```python\r\nimport textile\r\n\r\nsrc = u'This @example@ is \"neither\":/defn/neither complete *nor* trite, *though _simple_*.'\r\nbigsrc = src * 100  # Amplify any issues.\r\n\r\n%timeit textile.textile(src)\r\n# 1000 loops, best of 3: 1.4 ms per loop\r\n```\r\n\r\nThis doesn't seem bad.  Until you compare it to my experimental parser, which is almost 3x faster.\r\n\r\n```python\r\nfrom marrow.texting.engine import Parser\r\n\r\n%timeit Parser(src).render()\r\n# 1000 loops, best of 3: 510 µs per loop\r\n```\r\n\r\nThe output of the engines on this sample is nearly identical: (only difference is an inexplicable leading tab in the `python-textile` version)\r\n\r\n```python\r\n\r\ntextile.textile(src).strip() == Parser(src).render()  # True\r\n```\r\n\r\nIt gets worse when using the 100x larger `bigsrc` value, but it gets worse in a very unusual way:\r\n\r\n```\r\n%timeit Parser(bigsrc).render()\r\n# 10 loops, best of 3: 39.3 ms per loop\r\n\r\n%timeit textile.textile(bigsrc)\r\n# 1 loop, best of 3: 6.18 s per loop\r\n```\r\n\r\nThat's six *seconds*, or 4285x slower to process 100x as much text.  (Vs. 28x slower to process 100x as much text, which is actually an increase in efficiency and performance vs. the smaller source.) This is baffling.\r\n\r\n*Important Note:* I do not mean this ticket to be a spammy advertisement for my own package. My package was an experiment in parser design five years ago and not suitable for any real use.\r\n"},"comment":{"url":"https://api.github.com/repos/textile/python-textile/issues/comments/214031754","html_url":"https://github.com/textile/python-textile/issues/25#issuecomment-214031754","issue_url":"https://api.github.com/repos/textile/python-textile/issues/25","id":214031754,"user":{"login":"ikirudennis","id":1294347,"avatar_url":"https://avatars.githubusercontent.com/u/1294347?v=3","gravatar_id":"","url":"https://api.github.com/users/ikirudennis","html_url":"https://github.com/ikirudennis","followers_url":"https://api.github.com/users/ikirudennis/followers","following_url":"https://api.github.com/users/ikirudennis/following{/other_user}","gists_url":"https://api.github.com/users/ikirudennis/gists{/gist_id}","starred_url":"https://api.github.com/users/ikirudennis/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ikirudennis/subscriptions","organizations_url":"https://api.github.com/users/ikirudennis/orgs","repos_url":"https://api.github.com/users/ikirudennis/repos","events_url":"https://api.github.com/users/ikirudennis/events{/privacy}","received_events_url":"https://api.github.com/users/ikirudennis/received_events","type":"User","site_admin":false},"created_at":"2016-04-24T20:34:45Z","updated_at":"2016-04-24T20:34:45Z","body":"Firstly, I have some things to say on the conversation here, aside from the issue itself:\r\n\r\n@amcgregor, you can post a link to whatever you like.  Just know you're running the risk of me locking the conversation on this issue.  Yes, this is the internet, and while I don't have a right to not be offended, I do have some means of limiting your ability to purposefully offend me.  I had hoped that github was better than the internet at large.  Let's all do our part to keep things civil.\r\n\r\nFor what it's worth, I was feeling rather disheartened by this issue and  your subsequent follow-ups, and the IRC conversation didn't do much to change that.  I would like to thank @aclark73 for his input as it bolsters my point: the way you reported this issue comes across as a [seagull manager](https://en.wikipedia.org/wiki/Seagull_manager).  What sort of response were you expecting on this issue?\r\n\r\nI didn't mean to offend by closing the issue, but I thought I addressed the fact that I'm aware that this project is not particularly efficient and that it's something I'd like to improve.  It seemed to me, every project on github would have a \"make it faster\" open ticket which never closes.  Why keep an open ticket for a situation which is always the goal?  @amcgregor, I was considering asking you to open a new ticket which sticks to just the facts: \"python-textile is not speedy nor is it efficient. What can be done to improve it?\"  But would that change anything?\r\n\r\nSince this is an open source free project, which I use only minimally at work, I don't have a ton of time to devote to it.  I apologize for that.  Perhaps this project deserves better.  And perhaps I'd even accept some seagull management if I were getting paid for this work.  But there's no one else working on this, and no one's paying me.\r\n\r\nFinally, about the actual issue:\r\n\r\n@amcgregor, as I mentioned on IRC, I do apologize that this project has forced you to increase the complexity of your system.  You mention that HTML generated from a Word document is particularly troublesome.  Firstly, an example document would be IMMENSELY helpful for a project maintainer to test against.  I don't have Word, and can't remember the last time I used it.  (I am aware of how ugly Word's HTML is, I just never imagined someone might use textile to clean it up. Perhaps there's even a better way to clean up the HTML first before processing it with textile.)  Out of curiosity, how does marrow.texting compare to python-textile in a race with such a document?\r\n\r\nAlso, I tried pointing out on IRC that your example is flawed.  It generates a long string, with punctuation which does not resemble what would be considered typical input.  My initial thought was to just add a space to the end of `src`, but that didn't affect much.  I tested again with two newlines instead, and that brought the time down from about 20s to 487ms (my computer wasn't getting anywhere near your speeds :| ).  Yes, there are issues with python-textile and its processing speed.  Textile is intended for processing plaintext input.  If you're feeding it ugly HTML and complaining about the time it takes to process it, it kind of boils does to \"Doc, it hurts when I do *this*.\"  Don't be surprised when the response is, \"Don't do that.\""}}