raise the 1mb limit on code
-
In the past you've mentioned that we're free to do things like include the latest version of lodash ourselves for use. However, it appears you guys have introduced a 1MB limit on our code.
> Error while commiting to Screeps: { error: 'code length exceeds 1 MB limit' }
This is a problem. Many of the people in my alliance are bumping against that limit, especially as new features are being added to the game regularly. I think it's time to up the limit to something more reasonable (10mb would not be a bad start).
-
I concur with increasing it to 10MB!
-
I can see this being a problem.
-
1 MB code length limit has been there from the project launch in 2014. Increasing it will drastically affect servers performance, runtime servers may start to run out of memory and there will be huge lags during script parsing affecting overall tick duration.
-
Can you show us some numbers or something to show that it will affect things this much? I imagine only the people playing for awhile will use more code, and since we're already being careful about what is or isn't included due to the "require tax" it means we're going to self limit anyways.
-
So, since we can't upload our own lodash anymore, are you planning on a versioning mechanism so that we can opt in to newer versions of the library?
-
I'm also going to point out that in 2014 there were no minerals, boosts, power, terminals or market. There were no power creeps, which sound like they are going to require different code for each "power part". The game has grown, and so has the code it's required to run.
-
If RAM is a problem, then perhaps it could be counted in the CPU limit? I also support raising the limit to 10 MB.
-
Can you show us some numbers or something to show that it will affect things this muchI
I suggest you to wait until the open source server is released, and profile things yourself. And probably help with optimizations if you wish.
So, since we can’t upload our own lodash anymore?
Why “anymore”? What has changed?
are you planning on a versioning mechanism so that we can opt in to newer versions of the library
Sure, it’s on our Roadmap.
I’m also going to point out that in 2014 there were no minerals, boosts, power, terminals or market. There were no power creeps, which sound like they are going to require different code for each “power part”. The game has grown, and so has the code it’s required to run.
I’m not saying the limit will never grow. I mean it’s very hard to simply increase it right away due to current hardware memory limits. I’m sure we’ll find the solution in the future. 10 MB is quite unrealistic though.
-
> Why “anymore”? What has changed?
Lodash is over 500kb minified. My code is rapidly approaching that size myself. Were I to take a dependency on lodash 4 now (or worse yet, if I already _had_) then I would have some very interesting problems in a couple of months (probably shortly after power creeps dropped).
e: but I missed that that was on the roadmap, so thanks for that at least.
-
2mb would be great to start. Even 1.5mb to get started without causing a major issue on the server. We're happy to discuss/work around the number, but the 1mb limit is becoming an issue.
> I suggest you to wait until the open source server is released, and profile things yourself. And probably help with optimizations if you wish.
Yes, we all plan on working on the open source server to optimize things. That's why we're excited. However, you yourself said you're only releasing the game engine, not the infrastructure around it, so it's going to be difficult for us to benchmark your system.
> Why “anymore”? What has changed?
What's changed is that she's no longer GCL2 and has to write code for other things. Boosts alone take a solid amount of code.
-
2mb would be great to start. Even 1.5mb to get started without causing a major issue on the server. We’re happy to discuss/work around the number, but the 1mb limit is becoming an issue.
Well, we need to check how many players are close to this 1 MB limit. 2 MB seems feasible.
Yes, we all plan on working on the open source server to optimize things. That’s why we’re excited. However, you yourself said you’re only releasing the game engine, not the infrastructure around it, so it’s going to be difficult for us to benchmark your system.
Creating virtual machine context, code parsing and caching, generating runtime environment - these things will be the same. Only database retrieval and synchronization mechanisms will be different.
-
2mb would help a lot, and probably push this problem another year or so down the line.
-
As someone who is new and probably has less than 50KB of hand-written JS and no libraries, Grunt or other automation, I'd be curious to know: Is the 1MB limit across all code in Screeps? Per "branch"? Per source file?
Documenting this limitation in official documentation might be useful. Maybe add it here? http://support.screeps.com/hc/en-us/articles/205960931-Server-side-architecture-overview
-
I guess the issue is either fat dependencies or too much data in code form.
Pbly Lodash is the issue here. (being non gzipped)
If you need to use a newer version than the one provided, couldn't a simple upgrade of the lodash version do the trick ?
Artem would that be possible ?
Also, if you are really crafty (and desperate for lodash sugar) it is possible to compress lodash in a js string in a static file and then uncompress and eval it at runtime.
e.g. with something like that
https://github.com/pieroxy/lz-string/blob/master/libs/lz-string.min.js
To be honest a big part of what I like in this game are the constraints.
CPU, Memory, number of constructions site etc...
Each of them is a challenge and raise the 'fun' part of the game, at least for me.
1MB of source code of is a ridiculously high limit in that regard :s
If anything I thing it is too high.
Unless you store data in your code. (e.g. store static part of the map, or Cost Matrix preset for the rooms around your empire)
What you do with your MB of code is up to you.
If you choose to throw half of that to load external code, this is a decision you made, I don't see why this would require the limit to change.
In the spirit of:
When you hit the CPU limit, the anwser is: optimize your code and/or change your logic.
And not, ask the dev to increase the CPU limit.
My 2 cents.
-
I might be unpopular but I agree with Voronoi - I would vote for not increasing limits.
Yes, I am new to this game but I do have some years spent developing and designing various projects and tools. In business people often forget or cannot afford to think about optimization too much. Let's use this game to take the fun back to programming. Imho significant part of the game should be around searching for new and ever-better solutions for solving problems in the most efficient way. It is coding competition after all
-
If discussion is still going on here I'll weigh in as well. You're saying "Let's use this game to take the fun back to programming", but for me the fun in programming is using the tools I like to solve problems. With the code limit of 2MB, it's going to exclude the use of certain tools. I can see its use in a practical sense but not in a fun sense. What's fun is also different for different people.
-
Bringing this back up again. We have a 2MB limit, which is more than 1MB.
I'm bumping up against it now and am considering my options. One of them is a heavy refactor. Another is that the limit gets raised. A third is to store code in segments and eval or some other similar crazy scheme.
I think I'd prefer the second option where the code size limit is raised
-
To be honest, I was against raising the limit in the first place.
If there should be a change, I'm in favor of it being lowered back to 1mb.
I'm of the opinion that programming within constraints (cpu, memory etc) is part of the game and I find that quite enjoyable.
What exactly are you importing Tigga in order to bump over the 2mb? Have you considered minifying/trimming your vendors?
-
@atavus said in raise the 1mb limit on code:
What exactly are you importing Tigga in order to bump over the 2mb? Have you considered minifying/trimming the your vendors?
I'm not importing anything. Code takes up space! I'm fully automated and decision logic, especially for combat, is not simple. There's a lot of decisions to be made and a lot of factors to consider in each decision.
With regards to minifying. Should stack traces be readable? I think so. I agree that minifying is a solution, but then we're not really programming against constraints are we? We're just making debugging harder just to fit within a limit. I agree that programming against constraints is interesting in general, but I don't find code size an interesting constraint at all.
I'm kinda suprised that it's as low as 2MB, but maybe I don't understand the full end to end cost? 2MB is very small compared to our heap, for example and AFAIK it's only ever touched on a global reset which, with IVM, should be very rare.
