<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Python on Roads Less Taken</title><link>https://goran.krampe.se/categories/python/</link><description>Recent content in Python on Roads Less Taken</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 24 May 2016 00:00:00 +0000</lastBuildDate><atom:link href="https://goran.krampe.se/categories/python/index.xml" rel="self" type="application/rss+xml"/><item><title>Spry Performance</title><link>https://goran.krampe.se/2016/05/24/spry-performance/</link><pubDate>Tue, 24 May 2016 00:00:00 +0000</pubDate><guid>https://goran.krampe.se/2016/05/24/spry-performance/</guid><description>&lt;p>When writing Spry I am so far mainly ignoring performance. The general execution of Spry code will be a regular interpreter (although stackless I hope) and not a JIT. But that doesn&amp;rsquo;t prevent us from playing around and learning something!&lt;/p>
&lt;p>In this article I do some silly experiments around interpreter startup time and fooling around with 40 million element arrays. As usual, I am fully aware that the languages (Pharo Smalltalk, NodeJS, Python) I compare with a) have lots of other ways to do things b) may not have been used exactly as someone else would have done it. A truck load of salt required. Now&amp;hellip; let&amp;rsquo;s go!&lt;/p>
&lt;img src="https://goran.krampe.se/spry/thetruth.jpg" alt="The" style="display:block; margin:0 auto;"></description></item></channel></rss>