Author methane
Recipients brett.cannon, dino.viehland, eric.snow, methane, serhiy.storchaka, skrah
Date 2019-06-04.10:42:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAEfz+Tz1Uhr5CbpfOVOak=0QNtgQyRonaZqeNnYJbb_c-N=-vw@mail.gmail.com>
In-reply-to <1559643379.7.0.54033521601.issue36839@roundup.psfhosted.org>
Content
> Stefan Krah <stefan@bytereef.org> added the comment:
>
> 720MB <= "3-4 dozen" * 20 MB <= 960MB.  Per server.
>
> It has all been said. :-)

I don't understand what message you are replying.
I'm not interested in the number.  Who asked MBs / server?

Absolute number is not important when optimizing.

"I can reduce 3sec" is not important, unless total time is given.
3.5s -> 0.5s is great.  But 60 hours -> 59h59m57s is not great.

Hi didn't write anything about how much memory used by process.
Additionally, he measured serialized size, not memory usage.
It doesn't make any sense.

I don't trust even 20MB/process saving.  It is only in his mind.
This proposal is based on fantasy, not based on pragmatic
survey.

I think we should not take more time to discuss, until he proof the idea
by actually saving 20MB / process and provide detailed report.

>
> I don't understand the objections about alignment. malloc() and obmalloc()
> are at least 8-byte aligned, mmap() with NULL as the first parameter
> is page-aligned.
>

I think Serhiy meant alignment in pyc file.  bytes object in pyc file is not
aligned.  So it's bad idea to use mmap for pyc files.

But Instagram may use original serialize format instead of pyc files,
and it may align bytes object.  So it may be not a problem.
No one other than Instagrammer knows, because there is no
detailed information.
History
Date User Action Args
2019-06-04 10:42:22methanesetrecipients: + methane, brett.cannon, dino.viehland, skrah, eric.snow, serhiy.storchaka
2019-06-04 10:42:22methanelinkissue36839 messages
2019-06-04 10:42:22methanecreate