Brandon, you have absolutely no idea how the JVM works.
On Mon, Jul 23, 2012 at 8:41 PM, Drake <[email protected]> wrote:
>
> And not having time to sort through the duplicate imports which are
> definitely killing load time...
>
> And ignoring the fact that you are doing Dotted imports which add up to most
> if not the entire import which is slowing things down even more……. (Stars
> aren’t always bad because in GAE the IO is more of an issue than the compile
> time)
>
> And that those 3 things would likely speed load time by a lot, if not all of
> my 30% goal….
Try it.
I was tempted wait and see what kind of results you got ("not as much
as I had hoped" would have been hilarious), but that would just be
mean. Those changes aren't going to help because they have no effect
on compiled code. Literally, the Java compiler produces the *exact
same output*. This isn't Python; Java imports are just syntactic
sugar to the compiler.
I wasn't quite sure what to make of "not a single lazy load in the
project" so I'll just assume you don't have the faintest clue how
classloading works. But go ahead and suggest some specific code
changes that you think are going to make the app startup faster.
> The PolyLines String builder isn’t threaded, and profiling the app that
> seems to be really frakking slow.
>
> Create 4 threads and have each take ¼ of the array.
>
> I haven’t implemented the code but that should be about a 45% increase in
> speed.
Just. Wow.
First of all, the polylines string builder has no effect on instance
startup time. Try hitting urls which don't render polylines... same
10-15s startup time.
Second of all, you have a broken mental model of the relative
performance of various operations. It might be different in Python,
but I kinda doubt it. The computational cost of creating,
synchronizing, and joining a thread (plus all the security checks that
Google adds) are at least an order of magnitude more, and probably two
or three orders of magnitude more expensive than the cost of
assembling a polyline.
Seriously, try it. Especially try it in production.
> Am I required to actually check the changes in? or can you guys handle
> threading the slowest part of the code? ( I assume I’m optimizing for low
> volume and reduced latency)
You can submit a pull request if you actually come up with a real
improvement to startup time.
> Can I replace your Sha256 with something else? That is also eating a lot of
> CPU time and I can’t really tell from the 5 minutes looking at the code why
> you are doing that. Sha1 should suffice and would buy you 50% increase in
> speed on those requests that use it. And as far as I can tell that looks
> like all authenticated requests? It also doesn’t look like you are caching
> your HashCalculations? Based on privacy and such you may not want to
> memcache those… but at least store some number of them in instance memory.
This has nothing to do with startup time. And isn't a problem. And
what you say here doesn't really make sense anyways.
If you're wondering why /places requests are slow, I already know the
answer: Wikimapia is slow. Not my problem:
https://img.skitch.com/20120724-q517rqfg7mfhbndnbn4nfmwn89.jpg
Jeff
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
