Authoring Tools memory consumption

Avatar
JakeeeD
48 Posts
Posted Oct 19, 2011
I have noticed that when using Authoring Tools, my system eventually warns me that my virtual memory is low and the system is going to increase the pagefile size. This is pretty annoying since when that happens, compilation tools are ignoring every command and I have to restart the system before I can compile anything.

I have decreased the number of undos, and my draw distance is set to very low. However the program is laggy, and starts eventually to become unresponsive. I don't know if it's some kind of memory leak, since the Portal 1 SDK works well and both games run smoothly.

The question is, what can I do to improve the performance of Authoring Tools?

Advertisement
Registered users don’t see ads! Register now!
Avatar
CaretCaret
290 Posts
Posted Oct 19, 2011
Replied 7 minutes later
Buy more RAM?
Avatar
dinnesch
105 Posts
Posted Oct 19, 2011
Replied 22 minutes later
Judging from the warning you said you're getting, you run Windows XP? If yes, look here for a guide on how to increase your pagefile(virtual memory) size. If I guessed your OS wrongly, google is your friend :smile:

Compiling will take less resources if you lower quality - set RAD and VIS to fast, disable HDR.

Avatar
JakeeeD
48 Posts
Posted Oct 19, 2011
Replied 14 minutes later

dinnesch wrote:
Judging from the warning you said you're getting, you run Windows XP? If yes, look here for a guide on how to increase your pagefile(virtual memory) size. If I guessed your OS wrongly, google is your friend :smile:

Compiling will take less resources if you lower quality - set RAD and VIS to fast, disable HDR.

I guess you got me wrong. I don't want to increase the pagefile (the size is now optimal) or buy more ram (DDR1 is so slow that it would be insane to buy it more than 1gb since Socket 939 isn't so fast that the processor could efficiently handle more than 1gb of it). I meant that if there's something that you can do software-side.

Also, compiling time isn't a problem, just that the system starts to ignore the memory commands after increasing pagefile size.

Avatar
dinnesch
105 Posts
Posted Oct 19, 2011
Replied 17 minutes later

JakeeeD wrote:
I guess you got me wrong. I don't want to increase the pagefile (the size is now optimal) or buy more ram (DDR1 is so slow that it would be insane to buy it more than 1gb since Socket 939 isn't so fast that the processor could efficiently handle more than 1gb of it). I meant that if there's something that you can do software-side.

Also, compiling time isn't a problem, just that the system starts to ignore the memory commands after increasing pagefile size.

Your pagefile size is clearly not optimal for running heavy programs like Hammer. If you get the 'increasing pagefile size' warning it means you exceeded your currently set amount, and Windows temporarily expands it to prevent a crash and that can greatly slow down your computer. Just set it higher(like 2-4GB), restart your computer and it will likely work better.
Of course a big pagefile is slower than a lot of RAM, but I think it's about the best improvement to make 'software-side' with only 1GB of RAM...

Avatar
JakeeeD
48 Posts
Posted Oct 19, 2011
Replied 50 minutes later
The pagefile is already 1,5gb, I'll consider increasing it. However I don't think that it will reduce lag.

It's strange, since technically the programs are pretty much the same (SDK Hammer and Portal 2 Hammer), and the SDK Hammer works just fine.

Avatar
Robdon
204 Posts
Posted Oct 19, 2011
Replied 33 minutes later
Is it certain maps or all of them that lag?

I recently upgraded from 3GB mem -> 6GB, and it made a big different using hammer.

It uses alot of memory, 1GB just for hammer, and then the compiling progs use lots also on top of that, depending on your map size and usage.

Rob.

Avatar
iWork925
1,080 Posts
Posted Oct 19, 2011
Replied 3 hours later
I don't know how anyone would map with 1 gb of ram. I have 12gb and its still laggy as shit. If I was you I would buy ALOT more then 1 gb before I started mapping. Wait lemme guess... parent's computer? Tellem you need a better pc for school or something.
Avatar
JakeeeD
48 Posts
Posted Oct 20, 2011
Replied 10 hours later
I was frustrated and increased the pagefile size to 3gb. Zoooooom.

No Hammer lag or long Portal 2 loading screens.

Thanks guys.

Avatar
ChickenMobile
2,460 Posts
Posted Oct 21, 2011
Replied 21 hours later

JakeeeD wrote:
I was frustrated and increased the pagefile size to 3gb. Zoooooom.

That took some time for you to change it xD. I think my page file takes around a 1/6 of my terrabyte drive. :smile:
Not like I need all of it though...

Avatar
JakeeeD
48 Posts
Posted Oct 21, 2011
Replied 3 hours later

chickenmobile wrote:
JakeeeD wrote:

I was frustrated and increased the pagefile size to 3gb. Zoooooom.

That took some time for you to change it xD. I think my page file takes around a 1/6 of my terrabyte drive. :smile:
Not like I need all of it though...

The so-called recommendation is 1,5*RAM, so it's pretty unbalanced now. I don't think it does matter since my memory usage normally doesn't go over RAM to the pagefile, Hammer is an exception.

Avatar
Qmaster
8 Posts
Posted Dec 21, 2011
Replied 2 months later
I'm having a similar problem. Well 2 problems actually. Only it's immediately when I load up a map after starting hammer. The camera wsad movement is choppy and incredibly annoying, and the memory usage goes up every time I open and close a map, even the same map though it does it with every map I have. When it starts to hog about 1.5G of my RAM, I usually restart it, but the camera is still always jerky. What gets me is that, I have 4G of ram. SDK's hammer runs fine, and so does alien swarm's, and L4D2's hammer just like JakeeeD said. It's only in Portal 2 Authoring Tools that hammer seems to keep hogging my memory. It's like it never frees up memory on map file close, which is okay for the model browser but really, I mean come on!

I just don't get it, it didn't do this a couple months ago when the P2AT first came out.

Edit: Oh, and I just tested the old right click drag camera movement and it's jerky too. Its seems to want to move the camera a minimum of like 128 units or so. It's almost worth it just to map it in SDK and port it over.

Avatar
iWork925
1,080 Posts
Posted Dec 21, 2011
Replied 1 hour later
@Qmaster.

As previously stated in this thread:

1) Upgrade RAM / pagefile.
2) Consider better GFX card.
3) Lower these settings:

img

Avatar
JakeeeD
48 Posts
Posted Dec 22, 2011
Replied 6 hours later
img
It's very wonderful to work with this setup.

To me.

Avatar
Lpfreaky90
2,842 Posts
Posted Dec 22, 2011
Replied 7 hours later

Qmaster wrote:
...SDK's hammer runs fine, and so does alien swarm's, and L4D2's hammer just like JakeeeD said. It's only in Portal 2 Authoring Tools that hammer seems to keep hogging my memory. It's like it never frees up memory on map file close, which is okay for the model browser but really, I mean come on!

If portal 2 sdk is giving you problems: why don't you map your portal 2 maps in the alien swarm sdk?

Avatar
JakeeeD
48 Posts
Posted Dec 31, 2011
Replied 9 days later

lpfreaky90 wrote:
Qmaster wrote:

...SDK's hammer runs fine, and so does alien swarm's, and L4D2's hammer just like JakeeeD said. It's only in Portal 2 Authoring Tools that hammer seems to keep hogging my memory. It's like it never frees up memory on map file close, which is okay for the model browser but really, I mean come on!

If portal 2 sdk is giving you problems: why don't you map your portal 2 maps in the alien swarm sdk?

I recommend that, as I got everything fully working today, it's really more fun to map with bigger draw distance than 200 ; >

Advertisement
Registered users don’t see ads! Register now!
Avatar
DaMaGepy
361 Posts
Posted Jan 09, 2012
Replied 9 days later
Im not using virtual memory since 1998 :smile:
I always had enough ram for the actual windows and progs to handle it. 6 year ago 2GB was enough, till 2 year ago 4 was enough, and I upgraded to 8GB 1 year ago and it will be far enough for everything, all game and editing and such, and preserves HDDs.