Interesting.
When working on AstroCloud (http://astrocloudy.wordpress.com) we find out that
Bitmap and FormCanvas were way too slow. Performing a global modification
(e.g., changing a red for a blue) took long long time for very large images
(2000 x 2000 pixels).
We did some intensive profiling
On 10 Oct 2014, at 03:40, Benjamin Pollack wrote:
> On Sun, 05 Oct 2014 16:51:25 -0400, Sven Van Caekenberghe
> wrote:
> [snip]
>> Apart from that, the tokenisation is not very efficient, #lines is a copy of
>> your whole contents, so is the #split: and #trimmed. The algorithm sounds a
>> bi
On Sun, 05 Oct 2014 16:51:25 -0400, Sven Van Caekenberghe
wrote:
[snip]
Apart from that, the tokenisation is not very efficient, #lines is a
copy of your whole contents, so is the #split: and #trimmed. The
algorithm sounds a bit lazy as well, writing it 'on purpose' with an eye
for perfor
On Sun, 05 Oct 2014 16:51:25 -0400, Sven Van Caekenberghe
wrote:
Working with WideStrings is way slower than working with ByteStrings,
there is just no way around that. What is especially slow is the
automagic switch from ByteString to WideString, for example in a
String>>#streamContents
Hi Benjamin,
On 05 Oct 2014, at 22:37, Benjamin Pollack wrote:
> On Sun, 05 Oct 2014 10:36:31 -0400, Sven Van Caekenberghe
> wrote:
>
>> How come you got WideStrings ?
>> What does the input look like, can you give a partial example ?
>
> I'm guessing I got WideStrings because the file is in
On Sun, 05 Oct 2014 10:36:31 -0400, Sven Van Caekenberghe
wrote:
How come you got WideStrings ?
What does the input look like, can you give a partial example ?
I'm guessing I got WideStrings because the file is indeed in UTF-8, with
lots of characters outside the lower 128 code points. A
How come you got WideStrings ?
What does the input look like, can you give a partial example ?
On 05 Oct 2014, at 16:03, Benjamin Pollack wrote:
> On Fri, 03 Oct 2014 16:13:35 -0400, stepharo wrote:
>>> Looking at MessageTally, it seems at least half of that 278ms is spent
>>> noodling around i
On Fri, 03 Oct 2014 16:13:35 -0400, stepharo wrote:
Looking at MessageTally, it seems at least half of that 278ms is spent
noodling around in WideStrings and other small things that the Spur
object format ought to help with, so it'd be interesting to see how much
of a speed boost that gives with
as Stef says, we are close, but not there yet.
I’m working on it and I hope to have something really soon.
Esteban
> On 03 Oct 2014, at 22:13, stepharo wrote:
>
> Pharo has a new classbuilder with first class instance variables so the
> bootstrap took longer and
> doing so esteban and guille
Pharo has a new classbuilder with first class instance variables so the
bootstrap took longer and
doing so esteban and guille found bugs in Spur. So regularly but hidden
from the fame, esteban goes over it.
and we hope soon to have some images to beta testers.
My apologies if this is already sp
My apologies if this is already spelled out somewhere and I simply can't
find it, but are there any Spur images for Pharo yet? I can only find
Squeak ones. It's not a big deal either way; I was just playing with an
algorithm that, after very heavy optimization, I was able to get down to
about 278
11 matches
Mail list logo
