[tahoe-lafs-trac-stream] [Tahoe-LAFS] #419: pycryptopp uses up too much RAM

[Tahoe-LAFS]

#419: pycryptopp uses up too much RAM
-------------------------------+-------------------------------------------
     Reporter:  zooko          |      Owner:  nobody
         Type:  defect         |     Status:  reopened
     Priority:  minor          |  Milestone:  undecided
    Component:  code-encoding  |    Version:  1.0.0
   Resolution:                 |   Keywords:  memory pycryptopp performance
Launchpad Bug:                 |
-------------------------------+-------------------------------------------
Changes (by warner):

 * status:  closed => reopened
 * resolution:  fixed =>


Old description:

> Brian pointed out that the graph which shows the time to create a mutable
> ("SSK") file has shown a dramatic reduction in time recent:
>
> http://allmydata.org/tahoe-figleaf-graph/hanford.allmydata.com-
> tahoe_speedstats_SSK_creation.html
>
> The time to create an SSK is supposed to be dominated by the time to
> create a new RSA public/private keypair, which is a randomized process
> involving iteratively creating a big number and testing it for primality.
>
> Brian writes:
>
> {{{
> so, the munin performance graphs show a considerable speedup in mutable
> file creation time that occurred last tuesday around noon it affected
> both the colo and DSL tests, so I assume it was a code thing instead of a
> buildslave getting moved or something
>
> in addition, our 32-bit initial memory footprint went up by 6MB the only
> code change that appears relevant was the new reliance upon pycryptopp >=
> 0.5
>
> I can somewhat believe that the memory increase is due to the inclusion
> of the EC-DSA code but can you think of any reason why RSA key generation
> might have speed up by nearly a factor of 10?
> }}}

New description:

 Brian pointed out that the graph which shows the time to create a mutable
 ("SSK") file has shown a dramatic reduction in time recent:

 http://allmydata.org/tahoe-figleaf-graph/hanford.allmydata.com-
 tahoe_speedstats_SSK_creation.html

 The time to create an SSK is supposed to be dominated by the time to
 create a new RSA public/private keypair, which is a randomized process
 involving iteratively creating a big number and testing it for primality.

 Brian writes:

 {{{
 so, the munin performance graphs show a considerable speedup in mutable
 file creation time that occurred last tuesday around noon it affected both
 the colo and DSL tests, so I assume it was a code thing instead of a
 buildslave getting moved or something

 in addition, our 32-bit initial memory footprint went up by 6MB the only
 code change that appears relevant was the new reliance upon pycryptopp >=
 0.5

 I can somewhat believe that the memory increase is due to the inclusion of
 the EC-DSA code but can you think of any reason why RSA key generation
 might have speed up by nearly a factor of 10?
 }}}

--

Comment:

 Oops, I forgot to use the don't-close-Trac style of github commit message.
 This ticket might not be worth keeping around, but it shouldn't have been
 closed like that. Sorry!

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/419#comment:12>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage