Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New issue] re.compile does not use cache
--
ISSUES
1. [New issue] re.compile does not use cache
http://ironpython.codeplex.com/workitem/3514
On Wed, Apr 23, 2014 at 6:14 AM, Pawel Jasinski
wrote:
> asciidoc calls frequently re.compile.
> In case of cpython re.compile uses cache, where ironpython performs compile
> unconditionally.
> https://ironpython.codeplex.com/workitem/35146
Why would it repeatedly call compile? The point of compi
Official 2.7 documentation *hints* that re.compile does not cache
re.compile results (since some methods of module re actually are
caching result from re.compile):
https://docs.python.org/2/library/re.html#re.compile
On 23 April 2014 08:34, Jeff Hardy wrote:
> On Wed, Apr 23, 2014 at 6:14 AM, Pa
Sometimes documentation is not clear. The simple test confirms that cpython
re.compile caches results.
I can not imaging that asciidoc could provide reasonable performance if it
was not true. It does call multiple time compile with the same pattern.
rejap@eb60:~/Downloads$ python
Python 2.7.5+ (de
On Wed, Apr 23, 2014 at 9:34 AM, Jeff Hardy wrote:
> On Wed, Apr 23, 2014 at 6:14 AM, Pawel Jasinski
> wrote:
> > asciidoc calls frequently re.compile.
> > In case of cpython re.compile uses cache, where ironpython performs
> compile
> > unconditionally.
> > https://ironpython.codeplex.com/worki
On Wed, Apr 23, 2014 at 9:48 AM, Pawel Jasinski
wrote:
> asciidoc running with patched version of ironpython performs reasonably.
Can you run some numbers and add them in a comment on the pull request
or CP issue? I'm curious as to how much speedup asciidoc gets.
- Jeff
_
I have added the test numbers:
https://github.com/IronLanguages/main/pull/191
--pawel
On Wed, Apr 23, 2014 at 11:37 AM, Jeff Hardy wrote:
> On Wed, Apr 23, 2014 at 9:48 AM, Pawel Jasinski
> wrote:
> > asciidoc running with patched version of ironpython performs reasonably.
>
> Can you run some
Given the asciidoc workload using 3 different samples (hello world, user
guide, asciidoc documentation), the best results are when .net regexp
compilation is *disabled* and everything is cached.
When .net regexp compilation is enabled, the result are similar, but not
better.
Anyway, details can be
One more thing, just to calibrate the hello-world sample - how long do
`python -c 'print "hello, world"' and `ipy.exe 'print "hello, world"'`
take on your machine?
- Jeff
On Wed, Apr 23, 2014 at 12:39 PM, Pawel Jasinski
wrote:
> Given the asciidoc workload using 3 different samples (hello world,
I added the measurements to the PR.
Why is startup time of the ipy running out of development way up in
comparison with release?
--pawel
On Wed, Apr 23, 2014 at 1:57 PM, Jeff Hardy wrote:
> One more thing, just to calibrate the hello-world sample - how long do
> `python -c 'print "hello, world"
On Wed, Apr 23, 2014 at 1:25 PM, Pawel Jasinski
wrote:
> I added the measurements to the PR.
> Why is startup time of the ipy running out of development way up in
> comparison with release?
If you use the installer, NGEN. If not, I'm not sure.
- Jeff
_
this is the case
On Wed, Apr 23, 2014 at 2:30 PM, Jeff Hardy wrote:
> On Wed, Apr 23, 2014 at 1:25 PM, Pawel Jasinski
> wrote:
> > I added the measurements to the PR.
> > Why is startup time of the ipy running out of development way up in
> > comparison with release?
>
> If you use the install
12 matches
Mail list logo