Hi Jeff,
1) Polishing the navigation, as you said, it kind thought with GWT,
but I absolutely agree with you that it needs to be improved...
already some changes have been done, but going back at the same
position level on the map is just a mystery ;-)
2) I did not quite understand well what do
On Tue, Jun 7, 2011 at 11:07 PM, Giorgio Riccardi giorgio...@gmail.com wrote:
Hi Jeff,
1) Polishing the navigation, as you said, it kind thought with GWT,
but I absolutely agree with you that it needs to be improved...
already some changes have been done, but going back at the same
position
I am writing data using Google Spreadsheet data api
I am frequently getting the following error.
Timeout while fetching:
I have Googled for the above message, and there are few issues created on
the error. There seems to be no fix. Anyone has a workaround for this.
Note: I am using Appengine
Indeed Dennis's measurements are very suspicious. First you should do
a couple of warming ups on each of the implementations to prevent
pollution like the JDO classpath scan for enhanced classes (which is
one of the reasons for the high initial run). Then do a couple of run
to determine a range of
IIRC, the loading request latency doesn't affect the average time. It's an
average, I believe, and it's a moving window.
A long startup time, however, will result in the scheduler almost always
favoring putting items in the pending queue instead of spinning up new
instances, though. When
All mappers return this log message.
Please note it's an INFO message, so you shouldn't worry about it.
On Apr 20, 7:49 am, Santosh kumar kopp@gmail.com wrote:
Hi,
I have a mapper which is running fine without errors,
but finally it displaying Returning NOBODY because of SkipAdminCheck...
I don't think you can do anything on the App Engine end. Have you asked for
tips in the GData groups? It could be that the data you are writing is
inherently slow. Are there methods for writing data in chunks?
Ikai Lan
Developer Programs Engineer, Google App Engine
Blog:
On Wednesday, June 8, 2011 10:03:58 AM UTC+2, Jeff Schnitzer wrote:
Just leave the old window intact (but invisible) and render the new
one on top. When you restore the old window, it should be more or
less the same as it was. If the map widget gives you trouble, you
don't even need to
Yes, I am using the spreadsheet Batch to write the data in chunks.
-Aswath
On Wed, Jun 8, 2011 at 2:24 PM, Ikai Lan (Google) ika...@google.com wrote:
I don't think you can do anything on the App Engine end. Have you asked for
tips in the GData groups? It could be that the data you are writing
Sorry, when I said I have a GWT app that takes one major hit at
startup (possibly seconds) I meant the GWT client app itself, on
startup, has a login() call to the server that can take seconds to
process. Synchronizing facebook data and all that jazz.
I'm not terribly concerned about this since
Hi,
what is the error ?
Do you use static include in your jsp ?
On Jun 7, 1:16 pm, Shash Joshi sh...@perfode.com wrote:
My app runs locally, but when I go to deploy to GAE I get an compile
jsp error at line -1. I'm not doing anything fancy. Is there a do and
don'ts for jsp in GAE which I can
Yeah, that can potentially set things off, but I think you'll be fine.. If
the ratio is low, you will probably be okay, though. I'm saying this because
one way people have cheated the system if they had lots of slow requests
was by making lots and lots of essentially no-op requests via the task
Hi
I always was writing the info messages to the log (like described in
here :
http://code.google.com/appengine/docs/java/runtime.html#Logging)
I always used the .info method and the messages were perfectly shown
in the Admin Log page,
But recently i noticed the .info messages stopped to
I'm also getting the same error.
Any workarround for this???
Thanks,
Amit
On Fri, Apr 22, 2011 at 1:57 PM, Charms Styler charmssty...@gmail.comwrote:
I keep getting the following message when ever I Click on the *Datastore
Viewer* link at the Admin Control Panel. How can I view my App
It's not my benchmark, it's Slim3's :) ...but you're right, it's bogus. I
asked on the main appengine group too, and it turns out the low-level
benchmark is doing lazy loading. With that fixed, their numbers come out
like yours.
I found this one too, which also gets results like yours:
Hi All,
I am a little confused whether to take the plugin path or the GWT one.
True the plugin has GWT built into it but it seems to miss on of the
feature that I am now looking into, which is the MPV pattern. guess
you can do it manually with the plugin but here you there's an auto
generated
It is not bogus.
LazyList#size() fetches all data as follows:
public int size() {
resolveAllData();
return results.size();
}
Yasuo Higa
On Wed, Jun 8, 2011 at 11:32 PM, Dennis Peterson
dennisbpeter...@gmail.com wrote:
It's not my benchmark, it's Slim3's :) ...but you're right,
Apologies, no offense meant. My impression was that if you wanted to, say,
display all that data, it's going to take around 1000 ms to get it, not 1
ms.
On Wed, Jun 8, 2011 at 10:55 AM, Yasuo Higa higaya...@gmail.com wrote:
It is not bogus.
LazyList#size() fetches all data as follows:
public
I get...
The number of entities: 1
low level 1717 millis
slim3 1502 millis
objectify 2970 millis
jdo 3485 millis
probably should modify this example
to do an average of several runs
one important thing to note, is slim3 allows you
to update multiple entity types
in a single transaction.
not
Ok Jeff,
we'll try to sort it out also with your good suggestion
;-)
On Jun 8, 10:03 am, Jeff Schnitzer j...@infohazard.org wrote:
On Tue, Jun 7, 2011 at 11:07 PM, Giorgio Riccardi giorgio...@gmail.com
wrote:
Hi Jeff,
1) Polishing the navigation, as you said, it kind thought with GWT,
Hi Dennis,
You can see all sources.
http://slim3demo.appspot.com/performance/
Java runtime reflections are very very slow.
If you don't think so, please try it by you.
Yasuo Higa
On Thu, Jun 9, 2011 at 12:00 AM, Dennis Peterson
dennisbpeter...@gmail.com wrote:
Apologies, no offense meant. My
Hi Dennis,
The following document will help you about global transactions:
http://sites.google.com/site/slim3appengine/#gtx
Yasuo Higa
On Thu, Jun 9, 2011 at 12:33 AM, Dennis Peterson
dennisbpeter...@gmail.com wrote:
Those multi-entity transactions are definitely interesting to me. There's
Those multi-entity transactions are definitely interesting to me. There's
some overhead but no getting around that.
A while back I was playing around with some adhoc methods to do it in a
specific case, but I suspect Slim3 is more solid and maybe faster than what
I was doing. Definitely easier.
Very good =D
2011/6/8 Giorgio Riccardi giorgio...@gmail.com
Ok Jeff,
we'll try to sort it out also with your good suggestion
;-)
On Jun 8, 10:03 am, Jeff Schnitzer j...@infohazard.org wrote:
On Tue, Jun 7, 2011 at 11:07 PM, Giorgio Riccardi giorgio...@gmail.com
wrote:
Hi Jeff,
1)
No I agree, and slim3 looks very interesting to me. It was just the very
fast low-level times I was wondering about, but it looks like normally slim3
and low-level will be about the same speed.
On Wed, Jun 8, 2011 at 11:42 AM, Yasuo Higa higaya...@gmail.com wrote:
Hi Dennis,
You can see all
Does AppEngine support Servlet 3.0 ServletContainerInitializer for
code-based configuration of Servlet Container?
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to
You are wrong.
Try adding getProperty() calls to your LL performance test, and the
speed advantage of the LL API goes away. I don't know what to say
about Slim3, but here's my test case:
http://code.google.com/p/scratchmonkey/source/browse/#svn%2Fappengine%2Fperformance-test
I created 10,000
Unfortunately GAE does not support Servlet 3.0.
Please star: http://code.google.com/p/googleappengine/issues/detail?id=3091
Jeff
On Wed, Jun 8, 2011 at 11:45 AM, Marcel Overdijk
marceloverd...@gmail.com wrote:
Does AppEngine support Servlet 3.0 ServletContainerInitializer for
code-based
Silly me, already starred this some time ago...
Thanks anyway Jeff.
On Jun 8, 10:26 pm, Jeff Schnitzer j...@infohazard.org wrote:
Unfortunately GAE does not support Servlet 3.0.
Please star: http://code.google.com/p/googleappengine/issues/detail?id=3091
Jeff
On Wed, Jun 8, 2011 at 11:45
Slim3 is not only fast, the api is completely awesome. It has been my choice
for a year now for all gae projects.
It includes name safety and and amazing querying utils.
Very recommendable!
On Wed, Jun 8, 2011 at 3:41 PM, Jeff Schnitzer j...@infohazard.org wrote:
You are wrong.
Try adding
Slim3 may be a nice piece of software, but it has not been
demonstrated to be faster than anything (including JDO). It might or
might not be faster - I don't know - but based on the sloppy
benchmarking, I'm pretty certain that the people making this claim
don't know either.
There's another
Jeff, Objectify is a great project, I have used it a lot before slim3.
I didn't use slim3 global transactions yet, but I don't understand why you
attack that when that is the one feature that jdo/jpa/objectify/twig cannot
deliver.
Slim3 is indeed faster than any other because of the simple fact
What I want to provide is a fair and casual benchmark.
As jeff advised, I modified samples as follows:
for (Entity e : service.getBarListUsingLL()) {
e.getKey();
e.getProperty(sortValue);
}
for (Bar bar : service.getBarListUsingSlim3()) {
bar.getKey();
bar.getSortValue();
}
for
On Wed, Jun 8, 2011 at 4:26 PM, Gal Dolber gal.dol...@gmail.com wrote:
Slim3 is indeed faster than any other because of the simple fact that it
uses apt(code generation) instead of reflexion, the generated code it's
almost the same that you'll write by-hand to wrap the low-level api.
I'm
Thank you for fixing the benchmark.
I am very curious. According to this new benchmark - it's hard to
tell without pushing the buttons a lot of times, but there seems to be
a trend - Slim3 is somewhat faster than the Low Level API.
Doesn't Slim3 use the Low Level API underneath? How can it
Slim3 uses LL API.
To resolve a strange issue that slim3 is faster than LL, I tried the
following samples:
One:
AsyncDatastoreService ds =
DatastoreServiceFactory.getAsyncDatastoreService();
Query q = new Query(Bar);
PreparedQuery pq = ds.prepare(q);
ListEntity list =
36 matches
Mail list logo
